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Foreword 


Although  some  people  may  ask  whether  the  Air  Force’s  reliance  on  automated 
systems  is  wise,  few  of  them  would  argue  that  this  reliance  is  not  pervasive  and 
ever-increasing.  Over  the  past  decade,  units  have  developed  such  a  dependency 
on  automation — especially  that  provided  by  small  computers — that  they  can  no 
longer  perform  their  missions  without  automated  support.  Recent  events  in  the 
Middle  East  illustrate  that  the  modem  warrior  relies  on  technology  and  com¬ 
puters  to  fight  effectively.  The  likely  conflicts  of  the  future  will  demand  quick 
reaction  and  decisive  action;  they  will  truly  be  “come  as  you  are”  skirmishes. 
Contingencies  in  the  low-intensity  conflict  arena  certainly  fall  into  this  category. 
Clearly,  contingency  planners  must  consider  automation  along  with  logistics, 
security,  and  medical  needs  when  they  plan  for  battlefield  support. 

Maj  Mark  A.  Cochran  takes  a  practical  approach  to  the  problem  of  applying 
unit-level  automation  to  contingency  operations  in  low-intensity  conflict.  He 
examines  small  computers — the  most  common  source  of  automation  in  units — for 
their  general  ability  to  support  the  wartime  missions  of  units.  After  considering 
some  of  the  characteristics  of  contingency  operations  in  low-intensity  conflict,  he 
then  matches  the  automation  potential  of  small  computers  to  several  key 
missions.  Major  Cochran’s  recommendations  address  a  broad  range  of  issues 
that  could  help  streamline  the  planning  and  execution  of  unit-level  automation 
support;  they  also  pay  particular  attention  to  correlating  day-to-day  activities  to 
contingency-response  capabilities. 


BRYANT  P.  SHAW.  Col,  USAF 
Director 

Airpower  Research  Institute 
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Preface 


Hundreds  of  thousands  of  small  computers  are  used  every  day  in  the  Air  Force 
to  perform  all  sorts  of  functions.  Although  the  base-level  mainframe  computer 
is  not  threatened  with  extinction  in  the  near  future,  small  computers  will 
increasingly  become  more  integral  to  mission  accomplishment,  especially  at  the 
unit  level.  Small  computers  offer  many  potential  advantages  for  unit-level 
mission  support,  especially  when  larger  systems  are  impractical,  unavailable,  or 
unresponsive  to  rapidly  changing  user  needs.  These  advantages  have  been 
evident  in  daily  activities,  during  exercises,  and,  most  recently,  in  the  Persian 
Gulf. 

This  study  focuses  on  small  computers  as  a  potential  means  of  providing 
automated  support  to  units  involved  in  contingency  operations  in  low- intensity 
conflict  (LIC).  By  all  accounts,  LIC  is  the  arena  most  likely  to  see  US  military 
involvement  in  the  years  ahead.  Contingency  operations,  one  of  four  LIC 
categories,  apply  most  directly  to  the  Air  Force  since  they  often  involve  traditional 
applications  of  air  power.  Small  computers  can  be  effective  tools  for  units 
requiring  automated  support,  especially  in  the  unpredictable,  support-limited, 
and  time-sensitive  LIC  arena.  However,  functional-area  managers  must  take  a 
more  active  role  in  their  partnership  with  the  communications  computer  com¬ 
munity  in  order  to  plan  for  effective  small-computer  mission  support  from  the 
ground  up.  Although  Air  Force  units  have  made  a  tremendous  investment  in 
small  computers,  both  in  dollars  and  hours  of  development,  not  enough  effort 
has  gone  into  coordinating  and  integrating  their  mission-related  use  across 
functional  areas.  Unless  the  Air  Force  deals  with  this  issue,  it  may  be  less  able 
than  its  plans  indicate  to  rapidly  and  effectively  employ  forces  made  up  of  bits 
and  pieces  of  various  units  which  have  grown  accustomed  to  daily  small- 
computer  support. 

I  thank  Dr  Lawrence  Grinter,  my  research  advisor,  and  Dr  Marvin  Bassett,  my 
editor,  for  molding  my  thoughts  into  a  final  manuscript.  I  also  thank  Lt  Col  Leslie 
Kool,  Lt  Col  Richard  Clark,  and  Lt  Col  Manfred  Koczur  for  sticking  with  me 
through  good  times  and  bad.  Special  thanks  go  to  Mr  Woody  Hall,  my  sponsor 
at  Air  Force  Communications  Command. 


Finally,  above  all  others,  I  thank  my  wife,  Carole,  and  my  daughters,  Allyson 
and  Cassandra,  for  going  it  alone  so  marvelously  this  past  year.  I  love  you  now 
and  always.  , 


MARK  A.  COCHRAN,  Maj,  USAF 

Research  Fellow 

Alrpower  Research  Institute 
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Chapter  1 

Introduction 


The  Air  Force  prides  itself  on  being  the  “high  technology  service.”1  One 
of  the  technologies  the  Air  Force  invested  in  heavily  during  the  1980s — small 
computers — greatly  changed  the  way  many  of  its  people  do  their  jobs. 
Between  1982  and  the  end  of  the  decade,  the  Air  Force  purchased  over 
300,000  desktop  computers  for  units  in  nearly  every  functional  area.2 
Small  computers  provide  valuable  daily  assistance  to  such  functions  as 
operations,  maintenance,  communications,  civil  engineering,  security 
police,  services,  finance,  personnel,  chaplain,  and  a  host  of  others  that  keep 
the  Air  Force  running.  “You  go  into  specialized  operational  areas  and  see 
people  .  .  .  running  computers  there.  .  . .  Computer  people  have  become  so 
Important  and  so  proliferated  throughout  the  Air  Force  that  we  are  totally 
dependent  on  them.”3  The  more  accustomed  people  become  to  using  small 
computers  in  their  daily  jobs,  the  more  reliant  their  units  become  on  these 
machines  to  carry  out  their  missions  during  wartime.  Personnel  who 
routinely  use  small  computers  would  not  likely  want  to  give  up  this 
capability  if  they  were  sent  into  a  war  zone.  Indeed,  many  users  could  not 
easily  abandon  small  computers  since  they  either  no  longer  know  or  never 
learned  any  other  way  to  operate. 

Even  those  units  that  rely  primarily  on  the  base-level  mainframe,  or  large 
computer,  for  automated  support  might  find  themselves  needing  small- 
computer-based  automation  in  some  scenarios.  For  example,  small  com¬ 
puters  could  be  the  sole  source  of  readily  available  automated  support  when 
units  deploy,  operate  in  austere  conditions,  or  respond  to  crises  in  develop¬ 
ing  nations.  The  Air  Force  devotes  a  sizable  portion  of  its  planning  activity 
to  these  types  of  scenarios  but  gives  little  attention  to  the  automation 
requirements  of  units  that  participate  in  them.  Ironically,  planners  use  a 
variety  of  computers  to  support  the  planning  process  itself. 

This  study  examines  the  utility  of  small  computers  in  providing 
automated  support  for  units  involved  in  a  contingency  operation  in  low- 
intensity  conflict  (COLIC) — also  known  as  a  peacetime  contingency  aera¬ 
tion  (PCO) — and  demonstrates  the  need  for  a  coherent  Air  Force  policy  that 
addresses  their  use  in  a  full  range  of  conflict  scenarios.  Toward  that  end, 
the  remainder  of  chapter  1  examines  COLICs  and  unit-level  small-computer 
automation,  providing  examples  of  the  two  ways  that  typical  small- 
computer-based,  mission-critical  systems  are  developed.  Chapter  2  dis¬ 
cusses  small  computers  in  the  Air  Force — how  and  why  they  were  acquired 
by  units,  as  well  as  some  issues  constraining  their  effective  integration  into 
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unit-level  missions.  Chapter  3  details  the  adequacy  and  appropriateness — 
from  both  technical  and  managerial  perspectives — of  using  small  com¬ 
puters  to  support  units  during  COLICs.  Chapter  4  examines  how  these 
small  computers  might  effectively  support  several  key  functions  performed 
by  Air  Force  units  involved  in  COLICs.  Finally,  chapter  5  offers  some 
recommendations,  both  technical  and  managerial,  for  using  small  com¬ 
puters  to  implement  unit-level  automation  during  COLICs. 

Contingency  Operations  in  Low-Intensity  Conflict 

One  of  four  categories  of  low-intensity  conflict  (a  conflict  smaller  in  scope 
than  conventional  war  but  greater  than  routine  national  competition*), 
COLIC  encompasses  a  set  of  scenarios  that  lends  itself  especially  well  to 
automation  by  small  computers.  COLICs  include  shows  of  force,  evacua¬ 
tion  of  noncombatants,  rescue  and  recovery,  defensive  strikes  and  raids, 
unconventional  warfare,  and  civil  support  (e.g.,  drug  interdiction), ^  all  of 
which  often  involve  remote  operating  locations,  quick  responses,  unusual 
logistics  and  other  support,  short-term  objectives,  and  limited  or  rapidly 
changing  information.  Thus,  a  COLIC  requires  a  mission-support  pack¬ 
age,  including  automation,  similar  to  that  of  a  larger  military  campaign,  but 
one  that  is  mobile  as  well  as  rapidly  and  easily  employable. 

High-level  commentaiy  suggests  that  COLICs  deserve  special  attention 
by  war  planners.  For  example.  Gen  Colin  L.  Powell,  chairman  of  the  Joint 
Chiefs  of  Staff  (JCS),  emphasized  that  “for  the  contingency  no  one  evei 
predicted  or  planned  for,  we  have  an  enduring  defense  need  to  maintain 
ready  contingency  and  special  operations  forces.”7  Further,  noting  the 
relatively  high  probability  of  US  forces  becoming  involved  in  lesser  conflicts, 
Gen  Michael  J.  Dugan,  former  Air  Force  chief  of  staff,  said  that  “the  actual 
use  of  military  power  in  the  future  will  likely  be  oriented  toward  control  and 
containment  of  crisis,  rather  than  involvement  in  extended  wars  of  attri¬ 
tion."8  Clearly,  any  Air  Force  unit-level  automation  policy  that  considers 
wartime  support  must  deal  adequately  with  COLICs  and  related  conflicts. 

Rather  than  simply  using  entire  wings  or  groups,  COLICs  use  highly 
tailored  forces  to  optimize  the  skills  recuired  to  meet  the  contingency. 
These  forces  are  often  made  up  of  various  units  that  may  not  have  worked 
together  before  but  must  nevertheless  blend  into  a  cohesive  force  very 
quickly.9  This  factor  underscores  the  importance  of  planning  and  training. 
Because  contingency  planners  must  have  maximum  flexibility  to  mold  a 
force  package  out  of  these  disparate  units,  standardized  equipment  and 
procedures  are  essential  if  the  commander  is  to  quickly,  easily,  and 
effectively  integrate  all  force  elements  according  to  plan.  This  concept  is 
not  a  novel  one.  F-16  squadrons,  for  example,  use  similar  procedures, 
terminology,  tactics,  ordnance,  and  support  equipment  so  they  can  be 
effectively  blended  into  a  composite  strike  package  or  deployment  force. 
Most  automated  functions  supported  by  the  central  base-level  computer 


are  also  fairly  standardized  among  similar  types  of  units,  but  such  support 
does  not  lend  itself  to  COLICs  very  well.  Reliance  on  a  mainframe  computer 
inhibits  force  tailoring  below  the  wing  level  and  poses  difficult  problems  for 
rapid  deployment  and  sustainability  in  field  conditions.  Also,  because 
mainframe  computers  are  typically  more  difficult  and  costly  to  program 
than  small  computers,  mainframes  do  not  adapt  well  to  the  changing  or 
unique  mission  requirements  of  a  COLIC. 


Small-Computer-Based  Unit-Level  Automation 

Units  are  beginning  to  compensate  for  this  lack  of  flexible,  deployable, 
mission-critical  automation  by  adopting  small-comfuter- based  support. 
There  are  two  general  methods  of  small-computer  systems  development. 
One  relies  on  a  mission  expert  in  the  unit  who  knows  a  little  about  software 
system  development,  and  the  other  involves  software-development  experts 
at  a  central  site  who  know  a  little  about  the  unit  mission.  Neither  solution 
is  ideal.  An  example  of  each  may  help  illustrate  this  dilemma. 

Most  unit-level  automation  takes  place  in  the  units  themselves.  For 
instance.  FPLAN  (derived  from  “flight  planning")  is  a  computer  program  that 
performs  an  impressive  array  of  flight-planning  functions  for  tactical  fighter 
aircraft. 10  Developed  by  squadron-level  fighter  pilots,  who  then  distributed 
it  to  fighter  squadrons  flying  similar  aircraft  in  the  Tactical  Air  Command 
(TAC),  this  simple — yet  complete  and  accurate — program  was  well  received. 
The  authors  implemented  changes  and  enhancements  recommended  by 
other  pilots  throughout  TAC.  Over  the  years,  FPLAN  evolved  to  support  47 
tactical  fighter  aircraft  in  a  wide  range  of  flight  characteristics,  and  the 
fighter  community  adopted  it  as  a  standard.  The  program  even  inspired 
fighter  operations  managers  to  develop  a  ruggedized  (durable),  integrated 
flight-planning  system  that  also  incorporated  bombing  and  threat  analysis. 
Known  as  the  mission  support  system  (MSS),  this  system  comes  with 
integrated  logistics  and  centralized  professional  software  support  and  is 
deployed  throughout  the  tactical  air  forces.11 

Yet,  FPLAN’s  success  is  the  exception  rather  than  the  rule  for  small- 
computer  software  developed  in  Air  Force  units.  Clearly,  its  standardization 
and  widespread  adoption  were  due  primarily  to  the  extraordinaiy,  long-term 
commitment  of  a  very  few  people.  Generally  speaking,  this  process  is  not 
desirable  as  a  method  of  unit-level  automation  for  the  same  reason.  That 
is,  the  development  effort  is  almost  impossible  to  manage  since  the 
programmer  works  on  a  part-  or  spare-time  basis.  Furthermore,  the  results 
are  unpredictable  with  respect  to  time,  accuracy,  and  reliability  since  the 
program  creator  usually  has  no  training  in  software  development  and, 
consequently,  rarely  adheres  to  common  software-development  standards. 
In  short,  the  effort  is  a  lot  to  expect  of  one  or  two  people  and  simply  too 
unreliable  to  adopt  as  a  formal,  unit-level  automation  process. 
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The  converse  of  unmanaged,  unit-developed  software — that  is,  carefully 
managed,  centrally  developed  software — has  also  yielded  some  successes. 
For  example,  the  Air  Force  Logistics  Management  Center  (AFLMC)  created 
the  cargo  automated  loading  management  system  (CALMS)  to  help  load- 
masters  pack  the  cargo  bays  of  transport  aircraft  more  efficiently.  Because 
CALMS  itself  would  be  part  of  the  cargo  and  would  be  operated  by  nontech¬ 
nical  personnel,  considerations  of  size,  weight,  and  ease  of  use  dictated  that 
the  system  be  designed  specifically  for  small  computers.  AFLMC  main¬ 
tained  a  close  liaison  between  developers  and  users  and  even  tested  a 
prototype  system  in  the  field  during  the  Grenada  expedition.  Greatly 
increasing  airlift  capacity  through  loading  efficiency  and  speed,  CALMS  is 
now  used  throughout  the  Military  Airlift  Command  on  board  its  transport 
aircraft. 

Despite  this  success,  CALMS  evolved  through  a  series  of  operational 
impracticalities  and  took  several  years  to  reach  airlift  units  in  its  final  form. 
This  experience  highlights  two  common  complaints  that  Air  Force  users 
have  about  centrally  developed  software.  First,  unit  personnel  usually 
understand  most  operational  considerations  but  have  difficulty  com¬ 
municating  them  to  developers,  who  look  at  the  system  from  the  automated 
rather  than  the  operational  perspective.  Second,  several  years  is  just  too 
long  for  many  units  to  wait  for  a  small-computer-based  system. 

These  are  examples  of  successful  unit -level  automation.  But  for  each 
success,  unfortunately,  there  are  many  failures.  Obviously,  the  Air  Force 
must  seek  a  balance  between  unit-developed  and  centrally  developed 
software  for  small  computers.  Ironically,  the  strengths  of  one  method  are 
the  weaknesses  of  the  other:  units  know  the  problem  and  can  get  simple 
results  quickly,  while  software  professionals  employ  proper  procedures  in 
a  manageable  way. 


The  Critical  Role  of  Central  Functional  Managers 

If  the  Air  Force  really  wants  to  get  serious  about  unit-level  automation 
that  is  practical,  inexpensive,  deployable,  and  easy  to  use,12  then  it  must 
recognize  that  almost  limitless  computer  hardware  and  software  resources 
either  exist  today  in  the  units  or  could  exist  in  the  very  near  future  via 
cost-effective,  standard  small-systems  contracts.  These  resources  remain 
virtually  untapped  for  coordinated,  automated  support  of  unit  functions 
needed  in  wartime.  In  some  respects,  small  computers  represent  the  only 
type  of  automated  support  that  units  can  count  on  in  many  operational 
scenarios,  especially  those  generally  categorized  as  PCOs. 

To  exploit  the  small  computer  as  an  effective  mission-support  tool, 
however,  Air  Force  functional  managers  must  aggressively  coordinate  the 
use  of  small  computers  in  support  of  mission -critical  tasks  within  their 
functional  areas  and  oversee  additional  software  development,  if  required. 
Central  functional  organizations  include  the  Logistics  Management  Center, 
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the  Engineering  and  Services  Center,  the  Military  Personnel  Center,  the 
Medical  Systems  Center,  and  major  command  (MAJCOM)  operations  and 
training  staffs,  to  name  a  few.  To  balance  the  tug-of-war  between  units  and 
central  software-development  organizations,  the  functional  organizations 
must  provide  institutional  incentives  which 

1 .  encourage  units  to  adopt  more  formal  software-development  practices 
without  stifling  their  creativity  and  responsiveness  and 

2.  persuade  software  professionals  to  recognize  the  important  role  of  unit 
personnel  in  the  software-development  process  and  interact  more  closely 
with  them  at  each  step  along  the  way. 

These  incentives  will  necessarily  include  standardization  of  training,  logis¬ 
tics,  and  data  for  mission-critical,  small-computer  systems,  together  with 
an  evaluation  process  which  rewards  the  efficiency  (measured  in  terms  of 
time,  human  resources,  and  operational  employment)  achieved  in  applying 
these  standards. 

Once  functional  managers  determine  the  needs  for  small -computer 
systems,  as  determined  by  their  units,  and  establish  a  balanced  software- 
development  framework.  Air  Force  integration  and  planning  offices  can 
more  effectively  play  their  part  in  the  overall  process.  To  use  these  systems 
in  a  COLIC,  commanders  must  be  able  to  flexibly  mix  them,  much  as  the 
unit  missions  themselves  must  be  flexibly  tailored  to  meet  the  circumstan¬ 
ces  of  the  contingency.  This  overriding  need  for  flexibility  places  particular 
importance  on  Air  Force-level  integration  and  planning  to  coordinate  the 
efforts  of  the  various  functional  managers.  Thus,  successful  small-systems 
development  and  employment  must  rely  on  a  triad  of  unit-level, 
functional-level,  and  Air  Force-level  managers  and  technicians. 


Notes 

1 .  Lt  Col  Robert  L.  Johnson,  Jr. .  deputy  director  of  advertising  and  promotion.  Air  Force 
Recruiting  Service,  Randolph  AFB,  Tex. .  telephone  interview  with  author.  9  November  1990. 
This  attitude  is  quite  apparent  from  the  recruitment  advertising  on  radio,  television,  and  in 
print  media,  placing  particular  emphasis  on  high  technology  as  a  feature  distinguishing  the 
Air  Force  from  the  other  services.  In  fact,  according  to  Colonel  Johnson,  the  governing 
strategy  of  Air  Force  recruiting  Is  to  “strengthen  the  Air  Force  position  as  the  major 
technological  armed  force." 

2.  Capt  Carol  Rattan.  Standard  Systems  Center.  Gunter  AFB,  Ala.,  telephone  Interview 
wtth  author.  29  August  1990.  Vendors  delivered  186,000  small  computers  to  the  Air  Force 
from  standard  contracts.  Although  exact  numbers  are  not  known,  nearly  as  many  were 
apparently  delivered  from  sources  other  than  standard  contracts. 

3.  MaJ  Gen  Robert  H.  Ludwig,  “The  New  AFCC."  Intercom.  28  September  1990.  13. 

4.  Field  Manual  (FM)  100-20/Air  Force  Manual  (AFM)  2-20,  "Military  Operations  in 
Low-Intensity  Conflict,"  final  draft.  July  1988,  1-5. 

5.  Ibid..  47.  This  list  is  not  all-inclusive. 

6.  Ibid..  45-51.  COUCs  can  also  involve  relatively  large  forces  applied  over  longer 
periods  of  time  to  carry  out  broad  national  security  objectives.  This  type  of  COLIC  would 
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probably  have  sufficient  automation  due  to  the  size  of  the  deployed  support  package  or 
support  made  available  by  the  host  nation.  Operation  Desert  Shield  is  an  example  of  this 
type  of  COLIC.  However,  Saudi  Arabian  (host)  large-scale  automation  was  limited,  forcing 
United  States-based  computer  support  to  supplement  deployed  automation  capabilities. 

7.  Quoted  in  Air  Force  Policy  Letter  for  Commanders  (Washington,  D.C.:  Office  of  the 
Secretary  of  the  Air  Force.  August  1990).  1. 

8.  Ibid..  3. 

9.  Maj  Bradley  L.  Butler.  Planning  Considerations  for  the  Combat  Employment  of  Air 
Power  in  Peacetime  Contingency  Operations  (Langley  AFB.  Va.:  Army-Air  Force  Center  for 
Low  Intensity  Conflict,  May  1988).  5. 

10.  Lt  Col  Jerome  L.  Fleming,  4443d  Test  and  Evaluation  Group  fTEG),  Eglin  AFB.  Fla., 
telephone  Interview  with  the  author.  19  October  1990.  Colonel  Fleming  is  the  creator  of 
FPLAN.  Maj  John  C.  Thompson,  also  of  the  4443d  TEG.  is  primarily  responsible  for  the 
multiaircraft  version  of  FPLAN,  which  became  so  popular. 

1 1.  Colonel  Fleming  (see  note  10)  feels  that  the  MSS  has  not  achieved  FPLAN’s  degree 
of  success  because  MSS  software  attempts  to  do  more  than  the  hardware  permits,  creating 
problems  that  cannot  be  resolved  in  the  near  term.  FPLAN.  on  the  other  hand,  was  designed 
for  the  simplest  unit-level  hardware  from  the  outset  and  has  benefited  from  hardware 
improvements  over  the  years.  This  hardware  evolution  enhanced  the  users’  satisfaction 
and  built  on  the  positive  reputation  that  FPLAN  initially  earned  in  the  fighter  squadrons. 

12.  The  Air  Force  may  indeed  be  getting  more  serious  about  this  matter.  For  example. 
Headquarters  TAC  has  been  bouncing  the  phrase  unit-level  automation  around  for  several 
years.  In  almost  all  cases,  however,  unit-level  automation  Is  considered  only  in  the  context 
of  force-level  (above  wing-level)  automation. 


6 


Chapter  2 


Small  Computers  in  the  Air  Force 

An  examination  of  the  issues  surrounding  the  use  of  small  computers  to 
support  unit-level  missions  leads  one  to  wonder  why  these  machines  are 
not  better  integrated  into  the  Air  Force’s  concept  of  how  it  does  business. 
In  terms  of  numbers  alone,  small  computers  would  appear  to  play  an 
important  role  in  how  the  Air  Force  carries  out  its  day-to-day  functions  and. 
hence,  how  it  would  operate  during  contingencies.  This  chapter  examines 
a  few  possible  reasons  for  this  inconsistency  between  availability  and  usage. 
These  reasons  are  derived  primarily  from  two  issues:  (1)  the  emergence  of 
small-computer  popularity  in  Air  Force  units  and  the  computer 
community’s  Inability  to  cope  with  this  popularity  and  (2)  the  polarization 
of  management  and  user  viewpoints  that  advocate  centralized  and 
decentralized  use  of  computing  resources,  respectively,  and  the  resulting 
struggle  between  advocates  of  mainframe  and  small  computers. 

At  this  point,  a  clear  definition  of  a  small  computer  is  in  order.  Although 
definitions  vary  according  to  one’s  perspective  of  automation  technology, 
for  the  purposes  of  this  study,  a  small  computer  is  a  general-purpose  system 
which  is  small  enough  to  fit  on  top  of  a  desk.  Further,  it  has  all  of  the 
components — whether  internally  or  externally  connected — that  are  neces¬ 
sary  for  it  to  function  properly,  and  it  does  not  require  special  temperature 
controls  or  electrical  power  in  a  typical  office  environment.  One  would  be 
correct  in  concluding  that  this  definition  also  applies  to  the  microcomputer 
available  at  the  local  computer  store  because  that  is  exactly  the  type  of  small 
computer  the  Air  Force  has  purchased  in  large  numbers  over  the  past 
decade  and  is  the  one  it  must  consider  for  unit-level  automation  initiatives. 
An  examination  of  how  the  Air  Force  came  to  have  so  many  of  these  small 
computers  would  be  useful  because  the  path  Is  littered  with  lessons — some 
learned,  some  not. 


A  History  of  Air  Force 
Small-Computer  Acquisition 

In  the  late  1970s,  the  commercial  availability  of  small  computers — a  new 
phenomenon — had  little  impact  on  the  Air  Force.  A  few  systems  found  their 
way  into  such  organizations  as  research  and  development,  education  and 
training,  and  acquisition,  but  these  were  experimental  machines  as  far  as 
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the  Air  Force  was  concerned.  The  first  few  years  of  the  1980s,  however, 
were  a  very  different  story. 

In  1980  small  computers  sprang  upon  the  commercial  scene  in  a  big  way. 
The  small  or  personal  computers  (PC)  of  this  time  fell  into  two  categories. 
On  the  one  hand  were  machines,  such  as  those  made  by  Commodore  and 
Atari,  which  had  limited  power  and  catered  to  the  average  American 
household  in  terms  of  cost  and  the  type  of  application  (mostly  entertain¬ 
ment)  they  were  designed  for.  On  the  other  hand  were  machines  in  the 
mold  of  Apple  and  Tandy  (sold  by  Radio  Shack)  which  promised  more  than 
the  “home”  computers  in  power  and  flexibility  but  sacrificed  affordability 
and  ease  of  use.  Neither  type  had  much  appeal  to  businesses,  and  the 
companies  making  these  small  computers  didn’t  try  very  hard  to  change 
the  business  community’s  mind.  In  the  absence  of  an  industry  standard, 
the  Air  Force  wasn’t  interested  either — at  least  officially. 

Unofficially,  small  computers  were  finding  their  way  into  Air  Force  units. 
Although  the  Air  Force  purchased  some  of  these  computers,  most  were 
brought  to  the  office  from  home.  Predictably,  the  inability  of  these  different 
computers  to  share  data  or  applications  produced  a  great  deal  of  confusion 
and  frustration.  At  the  time,  computer  standardization  simply  did  not  exist , 
either  in  the  industry  or  in  the  Air  Force. 1  The  Air  Force  officially  sanctioned 
small-computer  technology  in  a  few  cases,  such  as  the  rather  large,  special 
acquisition  by  TAC  in  early  1981,  but  these  efforts  were  not  coordinated  or 
shared  with  other  organizations.2  The  industry  situation  was  about  to 
change  dramatically,  however. 

fn  the  latter  part  of  1981,  International  Business  Machines  (IBM)  Cor¬ 
poration  introduced  its  PC.  Unlike  the  other  companies  producing  small 
computers,  IBM  had  a  reputation  for  quality  engineering  and  support,  and 
its  long  history  in  the  computer  field  had  created  a  potent  marketing  arm. 
Perhaps  equally  important  to  observers  in  the  business  community,  IBM 
was  one  of  them — not  some  upstart  with  an  unproven  track  record.  Almost 
overnight,  a  small -computer  standard  was  created:  the  IBM  PC.  Air  Force 
automation  managers  who  were  struggling  to  find  a  way  to  clean  up  the 
small-computer  mess  now  had  a  hook  to  hang  their  standardization  hat  on. 
They  didn’t  delay. 

By  the  time  the  IBM  PC  was  unveiled,  the  National  Academy  of  Engineers 
had  completed  a  study  recommending  complete  standardization  of  small 
computers  in  the  Air  Force.  In  early  1982  the  Air  Force  Small  Computer/ 
Office  Automation  Service  Organization  (AFSCOASO)  was  formed  to  work 
on  standards.3  Later  that  year,  the  Air  Force  and  Navy  decided  to  team  up 
and  procure  the  same  brand  of  small  computer.4 

The  Air  Force  Computer  Acquisition  Center  (AFCAC)  at  Hanscom  AFB, 
Massachusetts — the  contracting  arm  of  AFSCOASO — began  standard 
small-computer  procurement  in  early  1983. 5  Initially,  AFCAC  sought  to 
purchase  10,000  systems  for  the  Air  Force  and  Navy  over  three  years  but 
ordered  this  number  within  the  first  10  months  after  awarding  the  contract 
in  October  1983. 6  Zenith  Data  Systems  eventually  delivered  more  than 
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32 .000  of  its  Z- 1 20  computers  to  the  Air  Force  alone  by  the  time  the  contract 
ended  in  late  1985 — one  year  early.7 

Almost  one  year  after  awarding  the  Z-120  contract,  the  Air  Force  and 
Navy  entered  into  another  agreement  with  Zenith,  this  time  to  meet  the 
demand  for  a  small-computer  system  which  could  process  classified  infor¬ 
mation.8  The  TEMPEST-certified9  Z-150s — and  later  the  improved  Z-200s 
and  Z-386s — found  their  way  onto  over  16,000  Air  Force  desks  by  the  time 
the  contract  ended  in  October  1989. 10 

Even  before  the  shortened  Z-120  contract  expired,  the  Air  Force  sought 
to  take  advantage  of  improvements  in  small-computer  technology  and 
provide  a  follow-on  contract  to  the  popular  Z-120  procurement.  Again, 
Zenith  won  the  contract  with  its  Z-248  system,  a  functional  equivalent  to 
the  newest  IBM  small  computer — the  AT.  The  contract  of  February  1986 
called  for  90,000  Z-248  systems  over  three  years. 1 1  By  the  end  of  this  time, 
however.  Air  Force  units  had  ordered  more  than  120,000  Z-248s.12 

Widespread  commercial  acceptance  of  new  technology  embodied  in  the 
lapheld  or  portable  computer  prompted  the  Air  Force  to  award  another 
contract  to  Zenith  in  September  1987.  Zenith's  lapheld,  the  Z-184,  essen¬ 
tially  could  do  everything  the  Z-150  and  even  the  Z-248  could  do,  but  in  a 
package  smaller  than  the  average  briefcase.13  Based  on  unit  surveys,  the 
contract  allowed  for  the  delivery  of  90,000  Z-184s  over  three  years.  4  The 
immense  popularity  of  the  Z-120  and  Z-248  justified  these  numbers. 
However,  only  about  1 8,000  were  delivered  by  the  eve  of  contract  expiration 
in  1990. 15  Had  the  Air  Force  finally  been  saturated  with  small  computers? 

If  the  latest  small-computer  contract  (Desktop  III,  awarded  to  Unisys 
Corporation  in  November  1989) 16  is  any  indication,  the  answer  is  “no.”  A 
year  after  the  Air  Force  awarded  the  contract,  orders  for  Desktop  III  systems 
were  still  backlogged  six  to  nine  months.17  Neither  is  the  Air  Force 
abandoning  other  standard  small-computer  contracts.  In  mid- 1991  follow- 
on  TEMPEST  and  lapheld  contracts  will  be  let,  anticipating  over  16.000  and 
90,000  orders,  respectively.  The  lapheld  contract  includes  organizations 
throughout  the  Department  of  Defense  (DOD)  and  will  span  five  years.18 

The  Air  Force’s  ongoing  commitment  to  buying  small  computers  in  large 
numbers  leads  one  to  conclude  that  factors  other  than  demand  must  have 
caused  the  slump  in  lapheld  deliveries  in  1989-90.  Indeed,  the  need  for 
and  size  of  standard  contracts  are  based  on  surveys  of  unit  demand.  In 
fact,  as  we  will  see,  management  limited  the  number  oflapheld  computers 
purchased.  Clearly,  a  possible  decline  in  the  popularity  of  small  computers 
has  never  been  an  issue. 


The  Roots  of  Small-Computer  Popularity 

The  unanticipated  and  overwhelming  response  to  the  Z-120  contract 
certainly  reflected  the  pent-up  demand  in  Air  Force  units  for  a  small 
computer  like  the  one  which  unit  members  could  buy  for  themselves  and 


9 


use  at  home.  Zenith  Data  Systems  enhanced  this  sort  of  commonality  even 
further  when  it  made  the  exact  computers  on  contract  available  to  govern¬ 
ment  employees  at  attractive  prices. 19  This  situation,  especially  in  the  early 
years  of  Air  Force  standard  small-computer  initiatives,  served  to  fan  the 
flame  of  small-computer  popularity  even  more. 

Small-computer  popularity  was  more  than  a  fad  or  a  marriage  of  con¬ 
venience,  however.  Units  all  across  the  Air  Force  put  small  computers  to 
work  in  ways  that  no  amount  of  planning  could  anticipate.  When  people 
realized  that  small  computers  could  help  them  do  their  jobs  more  quickly 
and  with  fewer  mistakes,  they  naturally  became  interested  in  them.  Neither 
was  this  “revolution"  limited  to  administrative  tasks  or  the  lowest  working 
levels.  Flying-squadron  operations  officers  saw  that  their  aircrews  could 
use  these  computers  to  perform  the  mundane,  time-consuming,  mathe¬ 
matical  tasks  of  flight  planning,  thereby  freeing  the  crews  to  discuss  mission 
conduct  and  tactics  in  greater  detail.20  A  small-computer  culture  developed 
as  more  people  in  more  missions  tried  to  find  innovative  ways  to  use  this 
new  technology. 

Budgetary  and  logistical  issues  added  organizational  support  for  this 
growing  culture.  Small  computers  had  become  inexpensive  enough  to  be 
within  the  budget  of  every  squadron-size  organization  in  the  Air  Force. 
Between  1978  and  1983,  the  price  of  a  comparable  small  computer  fell  from 
over  $2,500  to  less  than  $1,000 — a  decrease  of  over  60  percent.21  Small 
computers  also  required  relatively  little  upkeep.  In  the  rare  instances  when 
maintenance  was  required,  repairs  were  cheap  and  easily  performed — 
sometimes  by  Air  Force  electronics-maintenance  technicians.  These  fac¬ 
tors  made  it  extremely  hard  for  commanders  to  say  no — based  on  cost  and 
support  considerations — to  exuberant  small-computer  advocates  who 
wanted  to  buy  more  Zenith  PCs. 

Even  the  Air  Force  computer  community  made  small  computers  attrac¬ 
tive  to  units.  Before  the  advent  of  standard  small-computer  contracts,  a 
unit  that  wanted  to  buy  any  type  of  computer  had  to  proceed  as  if  it  were 
purchasing  a  large  mainframe.  The  lengthy  written  documents  to  describe 
the  operational  need  and  justify  the  purchase,  the  numerous  meetings  held 
to  refine  detailed  requirements,  and  the  complex  procurement  procedures 
forced  many  units  either  to  give  up22  or  pursue  alternative,  unauthorized 
routes  of  small-computer  acquisition.23  Standard  contracts  changed  all  of 
that.  With  a  minimum  of  paperwork  and  Justification,24  commanders  could 
order  small  computers — in  whatever  configuration  and  with  whatever 
software  their  units  desired — and  have  them  delivered  via  the  Air  Force 
supply  system. 

Perhaps  most  significantly,  standard  small-computer  contracts  allowed 
units  to  take  charge  of  their  own  automation  needs.  They  could  identify  an 
application,  apply  small-computer  Innovation  to  their  own  jobs,  and  break 
the  bonds  that  had  tied  them  to  the  data  automation  community  (and  its 
mainframe)  for  all  computer  support,  which — historically — had  been  mar¬ 
ginal  at  best.25 
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A  Legacy  of  Centralization 


In  the  days  of  mainframe-only  computing  (the  1950s  and  1960s),  these 
rare,  expensive  machines  required  large,  specially  designed  facilities  and 
staffs  uniquely  trained  in  computer  operations  and  programming  (these 
people,  incidentally,  could  not  easily  be  recruited  from  society  at  large).26 
Therefore,  the  Air  Force — like  all  organizations  during  that  time — placed 
stringent  restrictions  on  the  access  to  computer  facilities  (for  reasons  of 
security)  and  on  the  acquisition  of  new  computer  equipment  (for  reasons  of 
cost  and  support).  These  restrictions  led  to  the  establishment  of  a  body  of 
regulations  and  policies — or  controls — on  what  became  a  new  class  of  Air 
Force-owned  materiel:  automated  data  processing  equipment  (ADPE).  In 
order  to  implement  these  ADPE  controls,  the  Air  Force  formed  a  manage¬ 
ment  structure  around  the  ADPE  itself,  its  facilities,  and  its  assigned  tasks. 
Since  the  first  (in  1963  and  1964)  Air  Force-wide  implementation  of 
standard  ADPE -supported  supply  and  finance27 — both  of  which  are  central¬ 
ly  managed  and  universally  applied  functions — the  initial  framework  estab¬ 
lished  for  ADPE  operational  policies  emphasized  centralized  control  and 
management. 

In  retrospect,  adopting  a  central- management  viewpoint  made  sense. 
Each  Air  Force  base  had  only  one  or  two  large  computers,  housed  in  large, 
specially  designed  facilities  and  operated  by  personnel  whose  support 
functions  differed  markedly  from  those  of  their  peers.  The  rare,  expensive, 
fragile  ADPE  relied  heavily  on  commercial  support,  sharing  these  charac¬ 
teristics  with  another  type  of  Air  Force  equipment — airplanes.  Further, 
ADPE  specialists  had  more  in  common  with  aircrews  than  did  typical 
support  personnel  of  the  time,  in  that  they  were  highly  educated  and 
technically  oriented  and  possessed  skills  sought  by  the  private  sector. 
Indeed,  the  special  relationship  between  a  programmer /operator  and  a 
computer  is  not  unlike  that  between  a  pilot  and  an  airplane.  Thus,  the 
ADPE  and  its  support  personnel — like  the  flying  community — deserved 
special,  centralized  oversight  and  control. 

When  we  consider  actual  day-to-day  operations,  however,  the  analogy 
between  computing  and  flying  breaks  down.  First,  large  computers  were 
tied  to  their  bases  and  to  unique  support  facilities  on  those  bases.  There¬ 
fore.  the  Air  Force  could  not  move  these  computers  to  a  war  zone  unless 
they  happened  to  be  located  in  the  theater  of  operations.  Obviously, 
planners  did  not  place  this  limitation  on  airplanes.  Yet.  the  Air  Force 
invested  heavily  in  these  fixed-site  computers.  8  Second,  very  few  people 
in  the  Air  Force  (or  anywhere)  understood  this  new  technology — least  of  all 
senior  managers,  most  of  whom  were  pilots.  This  situation  led  to  the 
development  of  Air  Force  computer  policies  by  a  cadre  of  “computer- smart" 
people.  Unsurprisingly,  these  policies  and  their  implications  were  largely 
independent  of  mainstream  operational  planning.  Thus,  centralized  ADPE 
management  and  control  began  to  establish  a  “center  of  gravity"  different 
from  that  of  operations  and  other  support  functions.  Third,  the  goals  of 


11 


automation  were  to  realize  savings  in  expenditures  and  manpower — objec¬ 
tives  of  peacetime  organizations29 — rather  than  to  increase  the  number  of 
planes  shot  down  and  bombs  on  target — measures  of  the  flying  and, 
incidentally,  most  other  support  communities. 

What  the  Air  Force  was  left  with.  then,  was  an  overriding  ADPE  manage¬ 
ment  philosophy  emphasizing  centralization,  based  on  similarities  between 
airplanes  and  computers  and  those  who  operated  them.  Simultaneously, 
this  scenario  entailed  a  lack  of  central  Air  Force  ADPE  control  and  planning 
by  operations-oriented  leadership,  due  to  dissimilarities  between  computer 
and  airplane  employment,  goals,  and  technology.  This  schizophrenic  situa¬ 
tion  continued,  seemingly  oblivious  to  the  growing  Air  Force  dependence 
on  automation  and  the  corresponding  need  to  fully  integrate  this  automa¬ 
tion  into  central  Air  Force  planning.  By  the  time  small  computers  started 
to  appear  on  the  ADPE  scene,  Air  Force  dependency  on  automation  was 
already  taken  for  granted,30  but  the  operations  community  and  even  senior 
managers  were,  by  then,  on  the  outside  looking  in  at  a  dogmatic  computer 
bureaucracy  with  its  own  agenda.  The  computer  community  had  taken  on 
an  “us  versus  them"  mentality,  viewing  (perhaps  disdainfully)  everyone  else 
as  users.31 

In  the  interim,  centralization  had  grown  to  be  a  sort  of  religion  in  the  data 
automation  community.32  In  fact,  centralization  extended  beyond  control 
to  execution,  buoyed  by  a  computer  employment  “doctrine”  which  featured 
one  or  few  computers  serving  the  entire  base.  This  policy  was  in  marked 
contrast  to  the  prevailing  Air  Force  operational  philosophy  of  centralized 
control  but  decentralized  execution.  Undoubtedly,  the  introduction  of 
small  computers  represented  a  user  challenge  to  the  computer  community’s 
total-centralization  philosophy.  Data  automation,  as  the  computer  com¬ 
munity  was  now  labeled,  might  maintain  some  degree  of  central  control, 
but  central  management  was  in  question — and  central  execution  was 
clearly  impossible. 

In  all  fairness,  data  automation  was  not  capable  of  responding  properly 
to  the  small  computer  in  the  early  1980s.  For  nearly  20  years,  the 
established  community's  organizational  structures,  regulations,  and  work¬ 
ing  relationships  with  “the  outside  world"  were  geared  entirely  toward 
satisfying  only  those  demands  for  automation  which  could  stand  the  test 
of  repeated  justification  on  the  basis  of  cost  savings  or  mission  criticality — 
or  both.  After  all,  only  one  or  two  computers  were  available  to  serve 
everybody,  so  any  new  applications  for  one  functional  user  had  to  be 
weighed  against  the  possible  effects  on  all  other  functional  users.  In 
essence,  data  automation  played  one  user  against  the  other  in  a  competition 
for  a  scarce  resource — the  central  mainframe  computer.  When  almost  all 
users  became  dissatisfied  with  the  amount  of  support  (a  situation  data 
automation  referred  to  as  system  saturation),  central  computer  managers 
could  justify — with  the  help  of  frustrated  user  communities — the  need  for 
bigger  and  more  powerful  computers.  Thus,  the  data  automators  further 
solidified  their  important  role  (and  power)  in  the  Air  Force  hierarchy. 
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The  walls  came  tumbling  down  with  the  Z-120  contract.  Ironically,  one 
goal  of  this  contract  was  standardization,  which  data  automation  thought 
would  enhance  central  control  over  small-computer  purchases  and  applica¬ 
tions.33  What  happened  in  the  Air  Force  with  small  computers  is  akin  to 
what  has  since  happened  in  Eastern  Europe  with  centralized  Soviet  control. 
Data  automation  attempted  to  better  position  itself  to  meet  the  challenge 
of  unregulated  user  self-automation  by  taking  charge  of  (regulating)  the 
technological  threat  (small  computers)  rather  than  addressing  the  root  of 
the  problem  (frustration  with  the  centralized  system).  In  doing  so,  data 
automation  provided  an  authorized  vehicle  for  user  secession  (standard 
contracts)  and  lost  control  over  many  of  the  applications  of  computer 
technology — the  basis  of  its  control  and  power  in  the  first  place.  The  key 
to  this  miscalculation  by  data  automation  was  that  it  viewed  its  policies  and 
procedures  for  many  years  as  prudent  management  and  control,  but  users 
had  perceived  them  as  regulatory  and  overly  restrictive.34 

In  the  wake  of  the  small  computer  “revolution.”  data  automation  under¬ 
went  dramatic  changes.  It  was  now  in  the  unenviable  position  of  supporting 
the  central  base-level  computer  philosophy  while  coordinating  an  orderly 
migration — or  decentralization — to  unit-owned  and  -operated  small  com¬ 
puters.  Senior  Air  Force  leadership  now  recognized  the  importance  of 
automation  to  mission  accomplishment — at  all  levels  and  in  all  functions. 

At  the  same  time,  another  important  Air  Force  function — communica¬ 
tions — was  beginning  to  become  highly  dependent  on  digital  (computer) 
technology.  Computer  networks  had  evolved  steadily  during  the  late  1970s 
and  early  1980s.  These  networks,  in  turn,  were  highly  dependent  on 
communications  technology.35  Although  decentralizing  computing  power 
would  undoubtedly  increase  the  scope  of  computer  networks  and  place 
greater  demands  on  communications,  communications  specialists  were 
ill-equipped  to  deal  with  digital  technology.  In  an  apparent  marriage  made 
in  heaven,  the  Air  Force  communications  and  data  automation  functions 
merged  in  1984  under  a  new  deputy  chief  of  staff  for  information  systems 
(AF /SI).  This  merger  reached  all  the  way  to  the  base  level  and  Included  the 
ways  personnel  are  classified  according  to  skills  and  experiences.  The  most 
extensive  Air  Force  computer  network  of  the  time  was  the  DOD  worldwide 
militaiy  command  and  control  system.  To  emphasize  this  mission,  in  1986 
SI  changed  into  the  deputy  chief  of  staff  for  command,  control,  communica¬ 
tions.  and  computers  (AF/SC).36 

The  SC  community  retained  control  over  base-level  mainframes,  as  well 
as  most  dedicated  mission-support  computers,  and  had  a  bigger  voice  in 
Air  Force  policy-making  due  to  the  merger  and  SC's  elevated  status  on  the 
Air  Staff.  Although  the  standard  contracts  lifted  the  burdens  of  complex 
procurement  processes  and  overwrought  justification  documents,  the  new 
SC  community  still  maintained  some  degree  of  control  over  small-computer 
purchases.  This  influence  was  evident  with  regard  to  the  Z-184  lapheld 
contract. 


13 


As  stated  earlier,  only  a  fraction  of  the  initial  estimate  of  Z-184s  was 
actually  delivered  to  Air  Force  units.  Equally  capable  Z-184s  were  more 
expensive  than  Z-248s,  so  units  had  to  justify  the  extra  cost.  Most  units 
could  not  show  a  need  for  a  highly  portable  small  computer,  even  for 
deployed  wartime  support.  The  principal  reason  was  that  SC — hence  Air 
Force  policy,  which  was  tied  to  special-purpose  wartime  support  computers 
and  even  “deployable”  base-level  mainframe  systems — did  not  formally 
consider  standard  small  computers  usable  or  supportable  in  a  combat  zone. 
In  fact,  formal  policy  did  not  recognize  small  computers  as  a  critical 
component  of  mission  support  under  normal  circumstances. 


The  Management  Vacuum 

Despite  the  widespread  acquisition  of  small  computers  and  the  potential 
to  enjoy  greater  freedom  from  centralized  data  automation.  Air  Force  and 
MAJCOM  functional  managers  undertook  very  few  formal  initiatives  to 
apply  this  new  tool  to  helping  people  do  their  primary  jobs  easier  or  better. 
Perhaps  the  reason  is  that  small  computers  are  “personal"  computers: 
people  could  figure  out  how  to  best  use  them,  and — through  a  kind  of 
free-market  mechanism — word  of  these  applications  would  spread  through 
units  that  performed  similar  functions.  In  this  scenario,  a  de  facto  standard 
set  of  “systems”  would  eventually  emerge  which  could  then  point  the  way 
for  training,  logistics,  and  planning  for  operational  employment — especially 
if  a  unit  mission  dependency  evolved. 

This  "trickle  down”  technology  transfer  did  not  happen  very  efficiently. 
The  SC  community  was  wrestling  with  its  new  role  as  automation  and 
information  “integrator,”  while  clinging  to  its  bread-and-butter  base-level 
mainframe  computer.  Even  when  functional  managers  tried  to  take  an 
active  role  in  promoting  standardized  small-computer  use,  across-the- 
board  standards  rarely  developed.37  Everyone  seemed  to  want  to  “do  his 
own  thing,”  and  managers  did  not  develop  effective  incentives  to  encourage 
units  to  do  it  more  like  everybody  else.  Perhaps  the  issue  of  using  small 
computers  for  critical  automation  support  of  unit  missions  just  didn’t  seem 
all  that  urgent  to  the  functional  managers.  After  all.  the  base-level 
mainframe  had  assumed  that  role  years  earlier,  and — if  desired — the  units 
could  move  these  applications  to  their  own  midsize  computers,  which  would 
become  available  on  standard  contracts  in  the  future.  8 

On  the  surface,  small  computers  appeared  to  be  the  wedge  which  would 
pry  units  away  from  the  base-level  mainframe  computer — at  least  for  simple 
numerical  computation,  limited  information  storage  and  cataloging,  and 
short  reports  (all  of  which  would  be  important  during  and  immediately  after 
a  rapid  unit  deployment).  Although  the  importance  of  these  tasks  is  difficult 
to  accurately  assess,  managers  appear  to  perceive  them  as  an  insignificant 
portion  of  base-level  computer  work  load.  The  series  of  costly  upgrades 
made  to  the  standard  base-level  computers  Air  Force-wide  during  the  same 
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period  that  small  computers  were  bought  in  record  numbers39  may  have 
reflected  this  doubt  that  small  computers  would  substar  Hally  reduce  the 
critical  mission-support  work  load  of  the  mainframe.  In  this  management 
view — at  least  when  considering  the  entire  Air  Force — small  computers 
would  primarily  be  used  for  clerical  duties,  which  typically  have  little  impact 
on  mainframe  computer  utilization  and  (presumably)  could  be  handled 
without  automation  during  deployments. 

This  view  has  some  fallacies.  First,  without  a  viable,  centralized  manage¬ 
ment  program  for  small-computer  assets,  midlevel  and  upper-level 
managers  have  difficulty  determining  what  small  computers  are  actually 
used  for  in  the  units  and  how  important  the  units  consider  them  to  be. 
Managers  have  consistently  admitted  that  they  don’t  really  “have  a  handle 
on"  small-computer  management.40  Second,  because  units  initially  pur¬ 
chased  most  of  their  small  computers  by  using  administrative  or  “overall 
productivity  improvement"  justifications,41  there  might  be  a  tendency  to 
take  this  documented  usage  at  face  value  and  ignore  what  the  units  may 
otherwise  be  doing  with  small  computers.  Units  throughout  the  Air  Force 
have  developed  thousands  of  applications,  the  vast  majority  of  them  related 
to  how  the  units  do  their  jobs  functionally,  rather  than  administratively.42 
Third,  since  the  base-level  computer  work  load  increased  unabated  during 
the  1980s,  management  might  be  tempted  to  conclude  that  little,  if  any, 
mission-important  processing  was  migrating  from  mainframe  to  small 
computer.  Hence,  computer-support  planning,  if  required  at  all,  should 
focus  on  what  could  be  done  to  improve  the  base-level  computer  concept. 
Yet,  the  increase  in  base-level  computer  utilization  over  the  past  decade 
was  just  one  portion  of  the  increase  in  total  information  processing  during 
that  period.  Much  of  the  front-end  processing  for  the  mainframe  computer 
is  performed  by  the  units  on  small  computers,  and  quite  a  bit  of  this  work 
is  important  to  the  unit-level  missions. 

Maybe  the  simplest,  and  therefore  the  most  compelling,  reason  for 
functional  managers’  lack  of  initiative  in  small-computer  management  is  a 
dearth  of  expertise.  The  first  concern  that  leaders  of  a  revolution  face  when 
they  achieve  independence  is  the  fact  that  they  now  must  assume  the  roles 
and  responsibilities  of  the  people  they  displaced.  Despite  the  widespread 
complaints  about  poor  data  automation  supoor!  for  users,  at  least  the 
personnel  assigned  to  data  automation  knew  how  to  automate.  Standard 
contracts  made  the  acquisition  of  hardware  and  software  easier  but  did  not 
solve  automation  problems.  Although  the  reorganization  of  data  automa¬ 
tion  implicitly  represented  a  shift  toward  decentralization,  data  automation 
resources  were  not  dispersed  to  the  functional  areas.  Generally,  users  had 
to  create  their  own  "automation  centers"  virtually  from  scratch.  Tech¬ 
nicians  could  be  hired,  but  management  lacked  the  experience  and  training 
necessary  to  make  any  reasonable  degree  of  decentralization  a  success. 
Although  the  small  computer  may  have  been  the  catalyst  for  newfound 
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automation  power  in  many  functional  areas,  small-computer  exploitation 
naturally  took  a  back  seat  to  more  pressing  organizational  and  management 
issues. 

Issues  of  small-computer  utility  and  utilization  aside,  compelling  reasons 
started  to  emerge  for  developing  a  standardized  concept  for  employing  small 
computers.  Many  support  missions  had  formed  a  dependency  on  automa¬ 
tion.  especially  that  provided  by  the  base-level  mainframe  computer.43  This 
reliance  posed  a  dilemma  for  planners  looking  for  ways  to  automate  their 
functions  during  deployed  operations,  since  mainframe  computers  didn’t 
lend  themselves  very  well  to  deployment — especially  rapid  deployment. 
This  mission  was  becoming  increasingly  more  important  to  support  Air 
Force  responsibilities  in  a  worldwide  political  environment  that  was  quickly 
changing. 


The  Ubiquitous  Mainframe 

A  few  final  notes  about  the  base-level  computer  are  in  order.  It  did  in 
fact  exhibit  a  continual  increase  in  work  load  during  small  computer 
proliferation,  but  primarily  for  two  reasons  that  tend  to  mask  a  shift  toward 
the  utilization  of  small  computers.  First,  long-established  policies  and 
procedures  and  massive,  limited -access  data  bases  dictate  that  many  of  our 
large  Air  Force  automated  systems  rely  on  mainframe  computer  support. 
Even  units  and  functions  which,  operationally,  have  migrated  gradually 
from  the  base-le  U  computer  toward  small  computers  still  use  the 
mainframe  to  keep  track  of  their  big  data  bases.  Some  of  this  migration  is 
disguised  because  the  primary  users  of  these  systems  continue  to  access 
the  mainframe  for  data  and  reports  through  a  large,  base-wide  terminal 
network,  keeping  base-level  computer  utilization  high.  But  the  original 
“dumb”  terminals  generally  have  been  replaced  with  small  computers.44 
For  units  taking  advantage  of  this  capability,  the  small  computers  cffer  a 
degree  of  flexibility  and  responsiveness  for  manipulating  data  and  generat¬ 
ing  reports  that  was  never  achievable  with  the  mainframe  alone.  The 
base-level  mainframe  is  an  important  partner  in  this  process  because  units 
can  take  advantage  of  large  data  bases  managed  by  full-time  computer 
personnel  and  supported  technically  by  the  Air  Force  Standard  Systems 
Center  as  well  as  the  units'  MAJCOM. 

Second,  the  myriad  of  reports  and  banks  of  raw  data  that  were  passed 
between  base  units  and  their  headquarters  in  the  form  of  message  traffic 
now  make  up  a  sizable  portion  of  base-level  computer  processing.  Little  of 
this  information  is  critical  to  the  units’  missions;  most,  in  fact,  is  passed 
upwards  from  the  units  to  higher  headquarters  to  assist  policymakers. 
Small  computers  are  unlikely  to  pick  up  any  significant  amount  of  this 
processing.  The  data,  report  generation,  and  communications  are  handled 
entirely  by  the  base-level  system.  Perhaps  more  significantly  (and  maybe 
inappropriately),  the  units  themselves  do  not  perceive  this  capability  as 
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critical  for  performance  of  their  missions  and  therefore  devote  little  effort 
toward  automating  much  of  it  themselves. 


Unit-Developed  Software 

Units  tend  to  focus  on  Information  and  how  It  can  be  used  and,  if 
necessary,  any  automated  support  required  to  process  this  information  in 
order  to  get  their  jobs  done  more  effectively.  Quite  often,  because  the 
information  originates  at  their  level,  units  feel  compelled  to  automate  the 
processing  of  this  information  {i.e.,  write  software)  themselves  for  the  sake 
of  practicality  and  convenience.  Several  factors  influence  this  tendency  to 
self-automate.  First,  obtaining  professional  software  support  is  difficult, 
especially  if  the  tasks  being  automated  are  perceived — either  by  the  unit 
itself  or  the  SC  community — to  be  too  trivial  or  too  one-of-a-kind  to  survive 
the  rigorous  formal  process  of  software-support  approval.  Although  com¬ 
puter  hardware  became  easier  to  obtain,  the  SC  community  vigorously 
maintained  tight  controls  on  software  support.  Second,  even  if  units  obtain 
approval  for  professional  software  support,  the  process  of  accurately  and 
completely  specifying  operational  requirements  in  terms  a  software  en¬ 
gineer  can  understand,  not  to  mention  waiting  patiently  during  (usually) 
long  software-development  cycles,  sometimes  just  doesn’t  seem  worth  the 
effort.45  Thus,  if  some  of  their  people  can  create  software,  units  often  opt 
to  self-automate  because  they  understand  the  problem  and  can  keep  track 
of  the  software -development  process.  Small  computers  provide  units  the 
means  of  satisfying  their  software  needs. 

The  SC  community  actually  encourages  units  to  develop  their  own 
software  applications  because,  among  other  reasons,  it  simply  cannot 
support  eveiy  user  request.  However,  this  self-development  results  in 
problems  that  affect  many  areas — proper  manpower  utilization,  long-term 
software  support,  personnel  training,  processing  accuracy  and  validity, 
and,  of  course,  functional  software  standardization.  The  SC  community 
recognized  these  problems  and,  to  avoid  having  to  deal  with  them,  adamant¬ 
ly  maintained  that  support  for  user-developed  software  was  the  respon¬ 
sibility  of  the  user.  Although  many  unit  personnel  are  quite  competent  at 
programming  computers,  few  of  them  are  software-development  experts, 
and  none  of  them — excluding  computer-software  specialists  themselves — 
are  software  professionals.  In  addition,  units  rarely  share  information  or 
experiences  with  other  units  that  might  be  developing  similar  applications. 
Without  an  exceptionally  active  centralized  coordination  body,  this  dis¬ 
jointed  software-development  process  inevitably  results  in  much  wasted 
effort  “reinventing  the  wheel.” 

Although  the  battle  between  advocates  of  mainframes  and  small  com¬ 
puters  will  undoubtedly  rage  on  indefinitely,  two  conclusions  are  certain: 

(1)  both  large  and  small  computers  are  here  to  stay  in  the  Air  Force,  and 

(2)  if  the  Air  Force  is  to  use  them  effectively,  they  must  be  integrated  into 
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an  efficient  hardware  and  software  architecture  and  intelligently  managed 
as  an  entire  information  system.46  Meeting  the  latter  requirement  is  the 
principal  challenge  that  faces  automation  managers  in  the  1990s.  If  they 
are  successful,  the  Air  Force  will  enjoy  flexible  support  of  forces  employed 
in  the  widest  possible  range  of  military  commitments. 
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Chapter  3 


Taking  Advantage 
of  Small  Computers 

We  have  seen  that  the  Air  Force  uses  many  small  computers,  that  they 
are  popular — though  not  entirely  effective — vehicles  for  unit-level  automa¬ 
tion  initiatives,  and  that  the  communications-computer  community  has 
been  slow  to  integrate  them  into  its  overall  automation  scheme.  We  now 
turn  to  the  question  of  how  Air  Force  units  can  best  use  small  computers 
to  accomplish  their  missions.  Thus,  this  chapter  addresses  several  impor¬ 
tant  issues  concerning  small-computer  technology  (e.g.,  capability, 
reliability,  maintainability,  and  security)  and  management  (e.g.,  hardware 
and  software  standards,  integration  of  procedures,  training,  and  organiza¬ 
tional  and  support  structures). 


Technically  Speaking 

When  considering  whether  to  use  small  computers  to  support  important 
unit-level  missions,  one  must — at  a  minimum — answer  four  important 
technical  questions: 

1.  Is  a  small  computer  powerful  enough  to  perform  required  tasks? 

2.  Is  a  small  computer  reliable  and  rugged  enough  to  withstand  environ¬ 
ments  typical  of  deployed  operations? 

3.  If  a  small  computer  fails  in  some  way,  can  the  unit  repair  it  or  get  it 
repaired  easily? 

4.  Will  using  a  typical  Air  Force  small  computer  compromise  the  unit’s 
security  posture? 

Capability 

The  past  30  years  have  seen  tremendous  improvements  in  the  small 
computer's  processing  power,  data-storage  capacity,  and  data-communica- 
tions  capacity.  The  raw  computing  power  now  available  in  a  typical 
microprocessor  is  more  than  100,000  times  that  of  a  large  computer  25 
years  ago,  at  less  than  one-thousandth  the  cost.1  Indeed,  one  modem 
small -computer  system,  at  a  fraction  of  the  cost,  can  match  the  combined 
power  of  all  Air  Force  computers  in  1969,  when  the  first-generation  base- 
level  computers  were  fielded.2  Small  computers  commonly  found  in  the  Aft- 
Force  today,  despite  the  fact  that  they  represent  relatively  old  technology. 
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can  process  data  as  well  as  the  large  computers  which  units  relied  upon 
less  than  15  years  ago.  This  trend  shows  no  signs  of  abating.3 

In  terms  of  a  small  computer’s  usefulness  to  an  Air  Force  unit,  however, 
sheer  processing  speed  doesn’t  tell  the  whole  story.  The  ability  to  store  and 
exchange  a  sufficient  amount  of  information  is  equally  critical.  Here,  too, 
the  pace  of  technological  improvements  has  been  astounding.  For  example, 
small-computer  systems  now  routinely  include  magnetic  storage  devices 
capable  of  permanently  holding  over  100  million  characters  (100 
megabytes)  of  information.  The  typical  Air  Force  small  computer  can 
permanently  store  40  megabytes  and  can  save  data  on  an  unlimited  number 
of  removable  magnetic  (floppy)  disks,  each  holding  between  360,000  and 
1.44  million  bytes.  Optical  storage  technology,  now  so  popular  in  audio- 
video  electronics  and  available  with  the  newest  Air  Force  small  computer 
(Desktop  III),  raises  the  removable  media  storage  capacity  to  more  than  1 
billion  bytes  (one  gigabyte)  per  disk.4  The  internal  (temporary)  storage 
capacity  of  small  computers  also  increased  dramatically  in  the  1980s.5 
Once  restricted  to  a  mere  16,000  bytes  of  random  access  memory  (RAM), 
typical  small  computers  now  boast  one  megabyte  of  RAM.  The  Desktop  III 
expands  to  as  much  as  16  megabytes  of  RAM.  Such  a  capacity  for  both 
internal  and  permanent  storage  easily  exceeds  that  of  mainframe  com¬ 
puters  as  recently  as  the  early  1980s. 

However,  units  seeking  to  automate  mission-critical  tasks  need  more 
than  raw  power  and  storage — they  must  be  able  to  share  information  among 
personnel  and  with  other  units.  Traditionally,  this  has  been  a  strength  of 
the  mainframe  and  a  weakness  of  the  small  computer.  Base-level  data 
communications  networks  typically  transfer  data  at  a  rate  of  1,200  bytes 
per  second  (9,600  bits  per  second — BPS),  and  high-speed  data  links  can 
transmit  at  19,200  BPS  or  greater.6  The  hardware,  software,  and  com- 
munications-line  quality  (the  level  of  background  noise)  required  to  sustain 
these  speeds  were  historically  limited  to  large-scale  computing  and  special 
applications,  and  were  vexy  costly.  These  limitations  no  longer  exist  for  the 
small  computer.  The  increased  power  of  small-computer  hardware  and 
software,  the  widespread  use  of  digital  (low-noise)  communications  cir¬ 
cuitry,  and  the  dramatic  decrease  in  the  cost  of  high-speed  communications 
equipment7  now  permit  the  cost-effective  operation  of  small  computers  as 
nodes  in  high-speed  communications  networks. 

The  prediction  that  everybody  will  someday  have  a  mainframe  computer 
on  top  of  his  desk  is  now  a  reality — at  least  in  terms  of  processing  power, 
data  storage  capacity,  and  communications  capability.  The  nature  of  the 
computer-assisted  tasks  that  units  need  to  perform  has  not  changed 
tremendously  over  the  past  several  years,  but  the  ability  of  small  computers 
to  perform  them  has.  Because  today’s  small  computer  resembles  the  Air 
Force  base-level  mainframe  of  not-too-many  years  ago — at  least  in  the  ways 
computer  power  is  measured — one  can  reasonably  conclude  that  the  small 
computer  is  powerful  enough  to  adequately  support  most  unit-level  mis¬ 
sions. 
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Reliability 

Exceptional  performance  by  a  computer  is  not  sufficient  unless  the 
system  is  reliable.  The  military  is  very  serious  about  reliability,  as 
evidenced  by  DOD’s  separate  set  of  standards  (military  specification — 
M1LSPEC)  for  almost  any  item  that  could  fail  or  contribute  to  the  failure  of 
another  piece  of  equipment.  In  the  past,  this  emphasis  on  reliability  led 
the  Air  Force  to  acquire  many  MILSPEC  computers,  both  small  and  large, 
for  mission-critical  and  field  applications.  This  has  not  been  the  trend  in 
recent  years,  though,  and  has  really  never  been  true  for  the  base-level 
mainframe  computers.8  Although  recently  acquired  small  computers 
designed  to*  mission  support  (such  as  TAC’s  mission  support  system 
mentioned  in  chapter  2)  are  externally  distinctive,  internally  they  are  quite 
similar  to  the  standard  small  computers  the  Air  Force  is  buying  for  “office 
use.”  That  is,  the  large-scale  and  very  large-scale  integrated  circuits  of 
commercial  computers  (such  as  the  Air  Force  standard  computers)  are 
incredibly  reliable9  and  generally  meet  MILSPEC  standards. 

But  reliability  entails  more  than  just  failure- resistant  circuitry.  The  MSS 
looks  distinctive  because  it  has  been  “ruggedized”  to  withstand  rough 
handling  during  deployment,  as  well  as  harsh  environmental  conditions  at 
its  final  destination.  Anecdotes  from  commercial  and  military  sources 
suggest  that  a  small  computer’s  internal  components  are  quite  durable.10 
The  cases  that  house  them — most  of  which  are  at  least  partially  made  of 
plastic — are  another  story,  however.  Because  the  Air  Force  needs  to  use  its 
current  stockpile  of  small  computers,  additional  protection  is  in  order — 
such  as  that  provided  by  custom-fitted  shipping  cases  readily  available  on 
the  commercial  market.  The  relatively  uniform  design  of  Air  Force  small 
computers — due  to  the  standardization  of  hardware — simplifies  the 
procurement  of  these  shipping  cases.  This  solution  is  preferable  to  the  more 
expensive  options  of  acquiring  a  "special”  ruggedized  small  computer  or 
retrofitting  existing  small  computers  with  rugged  cabinets. 

Small  computers  must  also  be  able  to  function  in  harsh  environments. 
Unstable  sources  of  electricity,  extreme  temperature  and  humidity,  and 
large  concentrations  of  airborne  particles  are  the  enemies  of  electronic  and 
electromechanical  equipment.  The  digital  technology  in  new  Air  Force 
aircraft  and  other  weapons  systems  was  designed  to  withstand  environ¬ 
mental  extremes,  thanks  to  MILSPEC.  but  that  of  standard  Air  Force  small 
computers  was  not.  A  few  simple  precautions,  however,  will  make  small 
computers  remarkably  resistant  to  environmental  conditions. 

Because  electricity  can  be  generated  at  virtually  any  location  and  because 
modem  power  supplies  can  accept  a  wide  range  of  electrical  quality.  Air 
Force  computers  will  not  want  for  adequate  electrical  power.1 1  In  short,  if 
telephones,  televisions,  and  coffee  pots  will  work  at  the  deployed  site,  so 
will  small  computers.  As  for  operating  temperatures,  electronic  com¬ 
ponents  and  motors  generate  their  own  heat,  meaning  that  extreme  cold  is 
much  less  of  a  problem  than  extreme  heat.  The  latter  condition  is  mitigated 
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by  the  fact  that  modem  low-power  integrated  circuits  generate  relatively 
little  heat  and  that  small  computers  equipped  with  fans  can  operate 
indefinitely  at  ambient  temperatures  up  to  about  92  degrees  Fahrenheit. 
Above  that  temperature,  one  must  use  external  fans  to  recycle  the  air  or, 
in  very  extreme  cases,  portable  air  conditioners.  This  is  not  a  significant 
limitation,  since  operators  have  about  the  same  heat  tolerance  as  their 
computers.  Very  low  humidity  can  cause  static  arcing,  either  inside  the 
machine  or  between  the  machine  and  the  person  using  it,  but  external 
grounding  can  greatly  reduce  this  problem.  High  humidity  is  normally  not 
a  problem  unless  it  takes  the  form  of  visible  condensation — which  can  cause 
electrical  shorting — or  airborne  particles,  which  can  combine  with  the 
moisture  in  the  air  and  deposit  a  kind  of  “mud"  on  the  electrical  com¬ 
ponents.  As  with  high  temperatures,  moving  air  can  reduce  humidity 
problems.  Even  in  the  absence  of  humid  conditions,  a  high  concentration 
of  airborne  particles  can  disrupt  the  operation  of  mechanical  components 
such  as  floppy-disk  drives  and  keyboards.  Using  a  plastic  keyboard  cover 
and  cleaning  the  components  with  compressed  air  (available  in  cans)  can 
help  prevent  these  particles  from  building  up. 

Unquestionably,  the  reliability  of  electronic  equipment  has  benefited  from 
advances  in  technology  during  the  past  decade.  As  for  Air  Force  small 
computers  that  do  not  meet  MILSPEC  for  physical  durability  and  environ¬ 
mental  tolerance,  the  implementation  of  simple,  cost-effective  measures  can 
make  small  computers  suitable  for  the  support  of  unit  missions,  both  at 
the  home  base  or  in  the  field. 

Maintainability 

In  many  ways,  reliability  and  maintainability  go  hand  in  hand.  If  small 
computers  do  not  break  very  often,  then  they  require  only  a  few  people  to 
maintain  them12  (the  fewer  the  personnel  in  a  deployed  location  the  better) 
and  only  a  few  spare  parts.  Furthermore,  since  virtually  all  of  a  unit’s  small 
computers  are  working  at  any  given  time,  failure  of  any  one  system  has 
little  impact  on  the  overall  operation.  Even  so,  prudence  demands  that  one 
provide  for  the  repair  or  replacement  of  broken  computers. 

Most  people  who  use  small  computers  daily  have  at  least  a  rudimentary 
knowledge  of  how  they  work.  This  does  not  imply  that  the  average  operator 
knows  digital  theory  or  the  architecture  of  Integrated  circuits.  It  does  mean 
that  the  average  operator  knows  that  a  problem  in  reading  a  floppy  disk, 
for  example,  points  to  a  defect — either  in  the  disk  itself  or  the  disk  drive.  In 
other  words,  most  users  of  small  computers  understand  the  basics  of 
troubleshooting — a  situation  which  can  save  maintenance  technicians  a 
great  deal  of  time. 13  Users  also  probably  know  how  to  clean  the  disk  drive, 
a  measure  that  can  prevent  maintenance  problems  altogether.  Therefore, 
the  users’  ability  to  troubleshoot  and  do  preventive  maintenance  figures 
prominently  in  determining  the  levels  of  upkeep  for  Air  Force  small  com¬ 
puters. 
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For  repairs  that  exceed  the  rudimentary  capability  of  operators,  units 
need  small-computer  maintenance  technicians.  Typical  Air  Force  bases 
have  very  few,  if  any,  personnel  trained  to  repair  standard  small  computers. 
Fortunately,  however,  some  mission-critical  systems  based  on  small  com¬ 
puters — such  as  the  MSS — are  maintained  by  personnel  trained  in  small- 
computer  repair.  These  people  would  deploy  with  their  units  and  could 
perform  maintenance  on  several  types  of  small  computers — not  just  the  one 
they  were  trained  to  support  (due  to  the  machines’  electronic  similarity). 
Since  small  computers  are  so  reliable,  technicians  will  have  time  to  support 
units  in  need  of  their  services.  Of  course,  the  Air  Force  must  identify  or 
pool  these  personnel  so  other  units  can  take  advantage  of  them. 

If  these  technicians  are  not  available,  units  with  dysfunctional  small 
computers  have  three  choices:  (1)  they  can  ship  the  machines  to  a  site 
which  has  a  maintenance  capability,  (2)  they  can  request  replacement 
machines  through  Air  Force  channels,  or  (3)  they  can  use  host-nation 
resources  to  repair  or  replace  the  machines.  The  first  option  is  time- 
consuming  (assuming  that  such  a  site  exists).  The  second  option,  theoreti¬ 
cally,  takes  less  time  (though  still  measured  in  days)  but  may  be  futile  given 
the  competing  priorities  of  other  resupply  requests.  The  third  option 
depends  on  the  unit’s  location  and  the  availability  of  locally  spendable 
funds.  (Of  course,  if  the  unit  is  in  hostile  territory,  then  this  option  is  not 
practical.)  Cost  is  not  a  prohibitive  constraint  since  small  computers  are 
relatively  inexpensive,  as  militaiy  equipment  goes.  Chances  are.  the  host 
nation  will  have  the  appropriate  facilities,  given  the  popularity  of  small 
computers  worldwide,  including  newly  developed  and  developing  nations. 
In  fact,  most  of  the  world  (including  the  Soviet  Union)  has  adopted  the  IBM 
PC  as  the  standard  for  compatibility,  as  has  the  Air  Force. 14 

Finally,  digital  circuitry  not  only  improves  the  reliability  of  small  com¬ 
puters,  but  also  simplifies  maintainability  in  two  ways.  First,  digital 
architectures  are  built  up  from  components,  each  of  which  has  a  very  well 
defined  function.  When  troubleshooting,  a  technician  can  usually  trace  the 
failure  of  a  particular  function  to  a  specific  component,  often  with  the  help 
of  diagnostic  software.  A  bad  component  can  be  replaced  without  affecting 
other  components — much  like  changing  a  light  bulb — or  repaired  with  a 
minimum  loss  of  operating  time.15  This  “board-swapping”  concept  is  the 
foundation  of  Integrated  avionics  maintenance  on  Air  Force  weapons  sys¬ 
tems.  Second,  digital  circuits  are  often  designed  to  perform  tests  (i.e., 
self-diagnostics)  that  identify  bad  components  to  the  user  or  maintenance 
technician — a  capability  which  simplifies  troubleshooting.16  In  the  case  of 
small  computers,  Air  Force  standard  contracts  require  both  diagnostic 
hardware  and  software.  Thus,  improvements  in  small -computer  main¬ 
tainability  have  kept  pace  with  those  in  capability  and  reliability:  indeed, 
maintainability  has  increased  over  10  times  since  the  early  1980s.17 
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Security 

Computer  security  Is  a  complex  and  sometimes  confusing  area. 18  On  the 
one  hand,  it  Involves  protecting  the  information  stored  on  computers  from 
unauthorized  access  or  tampering.  One  can  effect  this  type  of  security  with 
physical -access  controls  (locks,  for  example)  or  information-access  controls 
(such  as  passwords).  Physical  access  to  small  and  large  computers  is 
controlled  similarly.  Although  the  control  mechanisms  vary  little  among 
different  computers,  information  access  is  more  difficult  to  control  for  small 
computers  because  of  the  number  of  users  involved  (whereas  single,  large 
computers  are  centrally  controlled).  In  the  context  of  this  discussion, 
however,  access  control  is  not  a  significant  concern — especially  in  a 
deployed  location  where  access  is  closely  monitored. 

On  the  other  hand,  computer  security  involves  preventing  adversaries 
from  exploiting  a  system's  communications  and  electronic  emanations  to 
tap  that  system’s  store  of  data.  Whereas  communications  security  is 
usually  addressed  through  encryption  or  other  technical  means,  emana¬ 
tions  security  is  controlled  by  TEMPEST  standards.  Data-communications 
security  techniques  are  similar  for  all  computers,  including  small  ones,  but 
not  all  small  computers  meet  TEMPEST  standards.  Therefore,  TEMPEST 
is  central  to  any  discussion  of  small-computer  security. 

Although  the  TEMPEST  program  has  significantly  changed  over  the  past 
several  years,  the  basic  concept  is  still  valid.  Almost  all  types  of  electronic 
equipment  radiate  radio-frequency  (RF)  energy  to  some  degree.  Recognizing 
this  energy  as  a  source  of  electromagnetic  interference  and  (more  recently) 
a  potential  health  hazard,  the  Federal  Communications  Commission  (FCC) 
adopted  a  set  of  standards  which  grades  the  degree  of  RF  emissions 
produced  by  computers.  (Of  course,  TEMPEST  is  principally  concerned 
with  the  processing  of  classified  data  and  goes  beyond  the  FCC  standards.) 
As  mentioned  in  chapter  2.  the  Air  Force  made  available  several  TEMPEST- 
approved  small  computers  (i.e.,  those  specially  shielded  and  tested  to 
ensure  minimum  RF  radiation)  on  standard  contracts.  Units  which  cur¬ 
rently  process  classified  information  on  small  computers  must  do  so  using 
TEMPEST -certified  machines,  which  would  go  with  them  in  the  event  of 
deployment.  Therefore,  the  real  security  issue  is  the  degree  of  risk  accept¬ 
able  to  units  that  deploy  with  non-TEMPE^ST  small  computers. 

In  all  probability,  unclassified  information  processed  by  units’  small 
computers  would  become  classified  during  operational  deployments.  Even 
if  the  information  remained  unclassified,  an  enemy  might  be  able  to  use  it 
to  piece  together  a  picture  that  could  threaten  operations  security.  Unfor¬ 
tunately.  the  most  common  small  computer  in  the  Air  Force  (the  Z-248)  is 
a  strong  RF  emitter,  and  its  video  monitor  is  even  worse.  The  Desktop  III, 
though  much  better  than  the  Z-248,  also  emanates  unacceptably. 

Although  small -computer  security  is  a  significant  issue  for  conventional 
force  employments,  it  may  not  be  as  much  of  a  problem  for  peacetime 
contingency  operations.  After  all,  security  measures  must  be  weighed 
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against  the  intelligence-gathering  capabilities  of  the  adversary.  Anticipated 
PCO  scenarios  typically  envision  hostile  forces  with  limited  technical  means 
for  conducting  the  ultrasensitive  RF  monitoring — assuming  that  the  PCO 
involves  hostile  forces  at  all.  Simply  maintaining  reasonable  physical 
security  around  operating  locations  may  be  sufficient  to  deter  this  threat. 
The  operational  commander  should  be  aware  of  the  RF  emanation  ranges 
of  the  unit’s  electronic  equipment,  including  small  computers,  and  ensure 
that  potential  adversaries  cannot  set  up  monitoring  stations  within  these 
ranges. 

Based  on  their  capability,  reliability,  and  maintainability,  small  com¬ 
puters  seem  to  be  an  appropriate  means  of  automating  many  aspects  of 
unit-level  missions.  In  the  context  of  typical  PCOs,  the  risk  posed  by  the 
RF  emissions  of  standard  Air  Force  small  computers  may  be  offset  by  the 
advantages  that  small  computers  enjoy  over  large  or  expensive  special- 
purpose  computers.  Nevertheless,  one  must  also  address  several 
management -related  issues  before  endorsing  small  computers  for  mission- 
critical  unit  support. 


Management  by  Design 

Units  are  trying  to  take  advantage  of  their  small  computers,  but  they  need 
adequate  support  and  guidance.  Specifically,  the  SC  community  and 
functional  managers  must  develop  a  coherent,  customer-centered  small- 
computer  management  program  which  deals  with  standards,  procedures, 
training,  and  organizational  and  support  structures. 

Standards 

To  properly  manage  mission-related  use  of  small  computers  in  Air  Force 
units,  functional  managers  must  identify  standard  applications  for  mission 
tasks.  This  will  permit  functional  training  and  standardization  of  proce¬ 
dures  and  will  allow  planners  to  flexibly  tailor  contingency  support  pack¬ 
ages.  Basically,  these  applications  standards  will  come  from  two  sources: 
functional  and  other  Air  Force-level  technical  managers  (such  as  the  SC 
community),  and  the  units  themselves.  In  general,  managers  have  neither 
developed  Air  Force-wide  functional  standards  for  small  computers  sys¬ 
tematically  nor  have  these  standards  evolved  from  units  efficiently. 

In  defense  of  management,  the  Introduction  of  small  computers  Into  the 
workplace  has  been  rather  insidious.  They  were  purchased  by  units  and 
integrated  into  missions  over  a  relatively  long  period  of  time,  usually  without 
coordination  with  the  functional  staffs  at  headquarters.  Even  when  small- 
computer-based  systems  were  centrally  developed  and  universally  intro¬ 
duced  into  the  units  by  functional  managers,  many  units  tailored  them  to 
their  own  particular  missions,  without  regard  for  potential  benefits — or 
drawbacks— to  the  functional  community  at  large.  Consequently,  many 
“standard"  systems  are  by  no  means  standard  across  units,  and  functional 
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managers  cannot  plan  for  and  implement  changes  to  training  and  other 
support  to  better  reflect  the  units’  actual  situations. 

In  defense  of  the  units,  management  generally  ignored  small  computers 
as  a  means  of  standard  mission  support.  The  general  confusion  about  the 
capability  and  reliability  of  small  computers,  the  perception  of  small 
computers  as  exclusively  administrative  aids,  and  the  dispersed  authority 
for  small-computer  purchase  and  application  led  many  functional 
managers  to  believe  that  planning  for  their  standardized  use  as  mission- 
support  tools  was  not  feasible.  Consequently,  few  applications  for  unit- 
developed.  small-computer-based  mission  support  were  brought  to  the 
attention  of  functional  managers  and  then  introduced  to  units  across  the 
Air  Force  as  standards.  Units,  perceiving  a  lack  of  interest  up  the  functional 
chain  of  command  and  having  been  left  to  their  own  initiative,  responded 
predictably — they  automated  their  missions  as  best  they  could,  in  isolation 
from  other  units  or  people  performing  similar  tasks.  Units  seeking  assis¬ 
tance  had  no  place  to  turn  except  the  SC  community.  However,  SC  had 
assumed  a  “data  automation  mentality"19  due  to  limited  resources  and  a 
lack  of  understanding  about  the  missions  that  needed  small-computer 
support. 

To  be  effective,  a  standardization  program  must  be  the  product  of  a  joint 
effort  involving  the  technical  community,  the  functional  managers,  and  the 
units  themselves.  The  technical  community  (mainly  SC)  must  provide 
interoperable  hardware  and  general-purpose  software  packages  via  stan¬ 
dard  contracts  as  a  base  for  standard -applications  development  and  opera¬ 
tion.  Further,  this  group  must  establish  technical  standards,  including 
user-interface  paradigms,  data-representation  and  exchange  formats,  and 
small-systems  development  tools.  0  It  must  also  provide  a  framework  for 
developing  and  managing  standards  which  combines  unit -level  customer 
support,  integration  of  existing  and  planned  systems  within  functional 
areas,  across-function  information  system  interoperability,  and  acquisition 
planning  and  installation  consultation.  These  challenges  will  require  the 
SC  community  to  reevaluate  its  role  from  top  to  bottom,  throughout  the  Air 
Force. 

Functional  managers,  primarily  through  their  field  operating  agencies, 
must  establish  a  technical  and  management  team.  The  purpose  of  the  team 
would  be  to  ensure  that  unit-developed  applications  follow  a  clear  path  to 
functionwide  standardization  and  to  provide  units  with  the  guidance  and 
support  required  for  proper  development  and  introduction  of  applications 
standards.  It  would  work  closely  with  the  SC  community  and  the  MAJCOM 
functional  staffs  and  be.  in  essence,  the  bridge  between  the  technical  and 
practical  aspects  of  standardization.  Additional  duties  would  include  act¬ 
ing  as  (1)  the  liaison  with  counterparts  in  other  functional  areas  to  deter¬ 
mine  if  standard  applications  could  be  shared  or  easily  adapted  and  (2)  the 
primary  point  of  contact  for  centrally  developed  small-computer  systems 
within  the  functional  area,  regardless  of  the  source. 
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Units  must  recognize  the  potential  functionwide  application  of  their 
efforts  from  the  beginning  of  any  development  process  and,  therefore,  follow 
functional  and  technical  guidelines.  They  should  not  embark  on  any 
development  effort  before  exploring — through  SC  and  functional-support 
teams — what  is  already  available.  Units  must  make  their  requirements 
known  so  these  teams  can  provide  technical  and  managerial  support.  Most 
importantly,  the  units  must  provide  feedback  to  those  agencies  which 
support  them  so  the  gap  does  not  reopen  between  what  units  need  and  what 
functional  areas  can  deliver. 

Procedures 

When  a  job  is  automated,  one  often  notes  that  some  job  procedures  need 
to  be  changed  to  compensate  for  outmoded  methods,  misidentified  data 
requirements,  changed  organizational  relationships,  reduced  manning,  and 
the  like.  Initially,  users  may  identify  the  need  for  these  procedural  changes, 
but  after  a  period  of  time  the  automated  system  itself  may  represent  the 
only  formal  description  of  a  set  of  job  procedures.  In  these  cases,  the  system 
performs  both  the  training  and  operational  functions. 

Functional  managers  are  ultimately  responsible  for  establishing  stan¬ 
dardized  procedures  and  making  sure  that  training  and  resources  are 
available  to  carry  out  these  procedures.  Therefore,  they  must  carefully 
assess  the  effect  of  automation  on  procedures  which,  in  turn,  affect  training 
and  resources.  The  functional  managers  must  allow  for  this  influence  of 
automation  on  procedures  and  ensure  that  automated  systems  ultimately 
embody  the  appropriate  standardized  procedures.  Indeed,  procedural 
standardization  is  the  primary  justification  for  automated-systems  stan¬ 
dardization. 

Units  that  independently  develop  unique  mission-support  software  ap¬ 
plications — without  oversight  by  functional  management — will  develop  uni¬ 
que  procedures  for  these  tasks.  Thus,  personnel  moving  from  one  unit  to 
another  will  find  the  same  job  being  performed  very  differently.  This  lack 
of  procedural  standardization  increases  the  units’  training  work  load  and 
degrades  mission  capability — at  least  in  the  short  term.  In  a  contingency 
situation,  personnel  from  different  units  would  have  great  difficulty  working 
together  effectively  in  the  first  several  days. 

Functional  managers  can  avert  this  inefficiency  by  enforcing  procedural 
standardization  in  automated  systems,  but  without  suppressing  initiative 
and  creativity  on  the  part  of  unit  personnel.  The  single-point  functional 
team,  mentioned  in  the  discussion  on  standards,  can  assimilate  ideas  (on 
both  procedures  and  applications)  from  around  the  Air  Force  and  dissemi¬ 
nate  them  in  the  form  of  standards.  Unlike  the  units,  the  team  can  then 
coordinate  required  changes  in  training  and  other  support  with  the  ap¬ 
propriate  agencies  or  other  functional  areas  and  ensure  that  these  changes 
are  standardized. 
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Training 

In  general,  training  is  a  strength  of  the  Air  Force.  Carefully  developed 
formal  or  self-study  training  programs  help  personnel  learn  and  become 
proficient  at  their  technical  specialty.  When  procedures  change  or  new 
equipment  is  introduced,  functional  managers  try  to  make  sure  that  the 
appropriate  training  is  available  as  soon  as  possible.  At  the  unit  level, 
supervisors  modify  subordinates’  on-the-job  training  (OJT)  programs  to 
incorporate  job  changes.  For  the  most  part,  though,  this  process  has 
functioned  poorly  with  respect  to  microcomputers.21 

Few  supervisors  had  any  experience  managing  computer-based  opera¬ 
tions,  and  even  fewer  understood  computer  technology.22  Consequently, 
both  supervisors  and  subordinates  approached  small  computers  “ex¬ 
perimentally"  and  did  not  establish  formal  training  requirements  or  devise 
OJT  programs,  even  after  small-computer  usage  became  prevalent. 
Formal-training  managers  in  the  Air  Training  Command  (ATC)  were  left  out 
of  the  picture  altogether.  Even  under  the  best  circumstances,  however, 
small-computer  training  poses  some  unique  problems. 

As  noted  earlier,  the  Air  Force  purchases  most  small  computers  under 
the  banner  of  office  automation  rather  than  mission  support.  Consequent¬ 
ly,  small-computer  training  initially  covers  general  applications  such  as 
word  processing,  data-base  management,  and  use  of  spreadsheets.23 
Generally.  ATC,  the  MAJCOMs,  and  bases  have  offered  this  type  of  training 
on  demand,  after  small-computer  automation  is  already  in  place.  Hence, 
the  training  infrastructure  falls  to  incorporate  mission-related  small- 
computer  training  into  formal  programs  or  OJT  guidelines  quickly  enough 
to  be  useful  to  the  units.  To  Improve  this  situation.  Air  Force-level 
functional  managers  must  identify  units  that  use  small  computers  for  direct 
mission  support,  choose  a  set  of  standards  for  this  support,  determine  how 
automation  will  affect  procedures,  and  work  with  ATC  and  the  MAJCOMs 
to  provide  appropriate  pipeline  training  (e.g.,  technical  training)  and  on-site 
training  (e.g.,  from  field-training  teams  and  OJT  guidelines). 

Formalizing  small-computer  training  is  important  for  at  least  four 
reasons.  First,  as  just  pointed  out,  formal  training  anticipates  a  unit’s 
needs,  thereby  relieving  it  of  the  burden  and  expense  of  effecting  Its  own 
training.24  Second,  formal  training  establishes  common  ways  of  doing 
business  for  all  Air  Force  personnel  in  a  functional  area.  This  greatly 
reduces  the  need  for  retraining  because  a  person  moving  from  one  unit  to 
another  uses  similar  procedures  on  familiar  systems.  Further,  units  that 
perform  similar  functions  are  equally  capable  of  supporting  contingencies, 
giving  planners  more  flexibility  in  their  construction  of  a  contingency 
support  package.  Third,  the  Air  Force  formal  training  process  is  more 
predictable  and  manageable  than  a  collection  of  disjointed  local  training 
options  from  a  wide  range  of  sources,  most  of  which  are  not  related  to 
specific  mission  tasks.  Fourth,  initial  formal  training  takes  into  account 
important  aspects  of  adult  education,  such  as  relating  training  to  required 
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job  skills,  maintaining  a  close  correspondence  between  training  and  real-life 
situations,  reducing  the  perceived  threat  posed  by  automation,  and  "void¬ 
ing  the  disruption  of  established  wor  k  habits.25 

Organizational  and  Support  Structures 

It  is  an  unfortunate  fact  of  life  that  as  organizational  needs  and  objectives 
change,  organizational  structures  must  also  change.  Over  the  past  decade 
we  have  seen  that  advancing  technology,  which  affects  how  we  meet 
objectives,  can  force  changes  in  organizational  structures — take  for  ex¬ 
ample  the  upheavals  in  the  communications-computer  community.  The 
>\<r  Force,  as  well  as  businesses,  has  gone  through  much  of  this  turmoil, 
especially  since  the  widespread  Introduction  of  small  computers  into  the 
workplace.  Indications  are  that  such  change  is  far  from  over. 

The  information  presented  *n  *.  is  paper  thus  far  has  indicated  that  the 
Air  Force  has  had  slgnif.ca  growing  pains  attempting  to  deal  with 
automated  technology  in  an  orderly  manner.  Some  of  this  difficulty  has 
resulted  from  the  Air  Force’s  h-",ring  a  fuzzy  picture  of  where  unit-level 
automation  is  heading — or  should  be  heading.  It  is  also  due  to  struggles 
by  functional  areas  to  define  an  internal  framework  of  change  in  the  absen  ; 
of  clear  guidance  and,  unfortunately,  to  battles  between  functional  are^s 
over  responsibility  for  automation  in  general,  especially  as  it  affects  units. 

In  this  context.  I  propose  an  organizational  and  support  structure  that 
addresses  the  mission  needs  of  units  and  provides  oversight  and  integration 
mechanisms  to  Air  Force-level  managers.  Implied  organizational  changes 
may  be  unavoidable.26  Though  updated,  these  ideas  are  not  new  and  have 
been  used  in  the  most  recent  reorganization  of  Air  Force-level  functions.27 

Each  unit  (squadron  equivalent)  should  have  a  small-computer  support 
team,  usually  consisting  of  two  people  (depending  on  the  unit’s  size), 
responsible  for 

1.  identifying  and  coordinating  training,  logistics,  and  other  support 
requirements  with  the  base  SC  support  team  (the  source  of  standard 
hardware  and  general  applications)  and  functional  support  teams  (the 
source  of  standard  mission  applications); 

2.  coordinating  local  development  efforts  with  the  base  and  functional- 
area  support  teams; 

3.  overseeing  local  development  to  ensure  the  employment  of  proper 
tools,  techniques,  testing,  and  documentation; 

4.  forwarding  properly  completed,  locally  developed  applications  to  the 
functional-support  team  for  possible  functionwide  use  and  long-term  sup¬ 
port; 

5.  coordinating  the  Implementation  and  assessing  the  effects  of  standard 
small-computer  applications  distributed  by  the  base  or  functional-support 
teams;  and 

6.  recommending  automation-related  procedural  changes  to  the  ap¬ 
propriate  functional-support  teams. 
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Each  Air  Force  base  or  operating  location  {or  equivalent)  that  uses  small 
computers  should  have  a  technical  support  team  consisting  of  SC  personnel 
responsible  for 

1 .  coordinating  and  assisting  with  general  applications  training  for  local 
units; 

2.  providing  units  technical  consultation  services  on  standard  hardware 
and  general-purpose  applications; 

3.  coordinating  local  small-computer  logistics  and  maintenance  support 
for  units: 

4.  providing  training  and  other  assistance  on  development  standards 
and  practices  to  units  that  are  developing  applications; 

5.  maintaining  a  data  base  of  and/or  coordinating  the  distribution  of 
standard  Air  Force-developed  functional  and  general-purpose  applications; 
and 

6.  assisting  units  with  the  procurement  of  standard  hardware  and 
general-purpose  applications. 

Each  functional  area  represented  by  unit  personnel  who  do  mission- 
related  work  on  small  computers  should  have  a  support  team  (size  deter¬ 
mined  by  the  extent  of  unit-level  automation).  Usually  located  in  a  field 
operating  agency  (if  applicable),  the  team  would  be  responsible  for 

1 .  planning  and  coordinating  training  for  standard  mission  applications 
with  ATC  and  MAJCOM  functional  staffs; 

2.  identifyii,  ^  and  coordinating  mission-unique  logistics  and  other  sup¬ 
port  requlreme-  «.s  with  other  functional  areas  and  MAJCOM  staffs; 

3.  overseeing  unit-level  development  efforts  across  the  entire  functional 
area  to  prevent  duplication  of  effort  and  ensure  that  applications  reflect 
proper  operational  procedures; 

4.  coordinating  mission-applications  standards,  arranging  for  long-term 
support  (in-house  or  from  the  author  of  the  software  or  an  outside  agency), 
and  distributing  standard  applications  to  unit  personnel  (usually  through 
the  base  support  team); 

5.  making  recommendations  to  the  functional  manager  concerning  auto¬ 
mation-influenced  procedures;  and 

6.  coordinating  with  Air  Force-level  technical  support  agencies  (primar¬ 
ily  SC)  on  vertical  (within -function)  integration  and  horizontal  (between- 
function)  interoperability. 

The  SC  community  would  codify  most  Air  Force-level  technical  support 
functions  in  the  Standard  Systems  Center  and  the  Technology  Integration 
Center  under  the  operational  guidance  of  the  Air  Force  Communications 
Agency  (AFCA,  the  SC  field  operating  agency).  SC  responsibilities  should 
include 

1.  planning  and  coordinating  training  for  standard  small-computer 
hardware  and  general  applications  with  ATC,  MAJCOM  SC  staffs,  and 
base-level  SC  support  teams; 


2.  arranging  and  coordinating  standard  small-computer  logistics  and 
maintenance  support  and  assisting  functional  areas  with  mission -specific 
support; 

3.  establishing,  coordinating,  and  updating  technical  standards,  to  in¬ 
clude  development  tools  and  techniques,  user  interface,  data  storage  and 
exchange,  and  communications; 

4.  advising  functional  areas  on  vertical  systems  integration  and  oversee¬ 
ing  horizontal  systems  interoperability  (and  integration  if  required);  and 

5.  advising  other  technical  support  agencies  and  overseeing  small- 
computer  training  and  support  for  SC  staffs  and  SC  support  teams  at  all 
levels. 

Of  course,  this  is  only  a  notional  list  of  responsibilities  and  a  proposal  for 
dividing  them  among  functional  areas  and  the  SC  community  at  various 
levels.  In  general,  this  support  structure  exists  today  althov  «h  much  of  it 
is  informal  and  fragmented.  The  current  MAJCOM  small  compu  Lei  techni¬ 
cal  centers  are  missing  from  this  structure.  MAJCOMs  would,  no  doubt, 
maintain  a  degree  of  small-computer  expertise  somewhere  on  their  SC 
staffs.  Support  for  the  base  SC  teams,  who  are  now  supported  by  the  SCTC, 
would  be  primarily  through  functional-support  teams  and  the  central  SC 
team  within  AFCA.  MAJCOM  SC  staffs  would  be  mainly  involved  in 
small-computer  resource  allocation  and  logistics  planning. 

From  a  technical  standpoint,  the  small  computer  is  a  viable  means  for 
providing  automated  support  to  units  for  a  wide  range  of  mission-related 
applications.  Although  management  and  support  have  been  a  stumbling 
block  to  fully  taking  advantage  of  small  computers  in  the  past,  the  Air  Force 
can  turn  the  situation  around  if  it  assigns  proper  priorities  and  adopts 
effective  organizational  structures.  The  next  chapter  will  examine  several 
functions  in  the  Air  Force  that  can  benefit  from  the  mission  support 
provided  by  small  computers. 


Notes 

1.  Katherine  D.  Fishman,  The  Computer  Establishment  (New  York:  Harper  &  Row.  1981). 
414.  Fishman  points  out  that  (in  1981)  microprocessors  cost  1/100.000  what  equally 
powerful  large  computers  did  two  decades  earlier. 

2.  Patrick  Geisinger.  "Smaller  Is  Bigger."  Chief  Information  Officer,  November  1990, 
110-12.  Since  their  Introduction,  microcomputers  have  doubled  in  power  compared  to 
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Chapter  4 


Applying  Small  Computers  to 
Contingency  Operations  in 
Low-Intensity  Conflict 


As  previously  discussed,  several  issues  affect  units  that  currently  use 
small  computers  to  assist  with  mission  tasks  or  that  contemplate  using 
them  in  the  future.  Chapter  2  outlined  some  traditional  dilemmas  which 
units  face  when  they  seek  long-term  software  support,  either  internally  or 
from  dedicated  software -support  organizations.  Chapter  3  enumerated 
some  of  the  many  considerations  which  units  must  take  into  account  with 
respect  to  small-computer  capabilities  and  supportability.  These  discus¬ 
sions  showed  that  potential  problems  were  not  insurmountable.  Therefore, 
there  is  a  single,  key  issue  which  units  are  left  to  deal  with:  if  they  use 
small  computers  to  any  significant  extent  to  assist  with  critical  missions — 
ones  that  would  be  necessary  if  units  participated  in  a  conflict — they  will 
not  be  able  to  do  without  them  (or  at  least  functional  equivalents)  during 
contingencies.  Assuming  that  units  involved  in  “small"  contingencies  need 
small-computer  (or  equivalent)  support,  this  chapter  examines  these  con¬ 
tingencies.  as  well  as  a  few  ways  that  Air  Force  units  benefit — or  could 
benefit — from  exploiting  small -computer  capabilities. 


Focusing  on  Units 

Before  proceeding,  one  needs  a  working  definition  of  the  term  unit. 
According  to  the  Joint  Operations  Planning  System  (JOPS),  a  unit  is  an 
organization  which  can  be  independently  deployed  to  form  part  of  a  fighting 
force.1  For  the  Air  Force,  this  generally  means  a  squadron,  although  a 
group  and  even  a  wing  can  fall  into  this  definition ,  depending  on  the  nature 
of  the  contingency  and  the  force  structure  desired.  Smaller  organizational 
breakdowns  are  possible,  especially  in  the  areas  of  operations  and  main¬ 
tenance.  For  puiposes  of  discussion,  however,  this  chapter  assumes  the 
squadron  as  the  deployable  unit. 

As  discussed  earlier,  units  have  been  the  primaiy  source  of  self-automa¬ 
tion  initiatives  with  regard  to  small  computers.  In  some  cases,  functional 
managers  have  adopted  these  Initiatives  and  have  standardized  them,  more 
or  less,  for  similar  units  within  the  functional  area.  In  other  cases, 
unit-level  automation  initiatives  have  originated  with  the  functional 
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managers  and  their  staffs.  The  source  of  small-computer  automation  Is  not 
important — the  fact  remains  that  many  units  have  become  accustomed  to 
relying  on  small  computers  to  help  them  perform  their  day-to-day  missions. 
Although  some  observers  point  out  that  peacetime  and  wartime  duties  are 
often  considered  independently  of  each  other,  the  hard  realities  of  contin¬ 
gencies — especially  those  falling  into  the  arena  of  low-intensity  conflict — 
dictate  that  the  peacetime-wartime  distinction  not  be  made. 


Contingency  Operations  in  Low-Intensity 
Conflict:  Something  Different 

The  very  nature  of  contingencies  places  severe  constraints  on  planners 
and  operational  participants  (i.e..  units).  First,  contingencies  almost  al¬ 
ways  require  a  quick  response.  Second,  they  are  likely  to  require  operations 
in  a  geographical  area  or  physical  environment  which  differs  from  that  of 
the  home  base  or  exercise  location.  Third,  one  can  expect  contingency 
operations  to  place  greater  demands  on  communications,  coordination,  and 
support  channels  than  is  the  case  during  routine  operations  and  planned 
exercises.  Finally,  contingencies  will  be  more  demanding  than  the  day-to- 
day  duties  of  these  personnel.  Predicting  how  these  constraints  will  affect 
mission  accomplishment  by  unit  personnel  is  not  always  easy. 

A  contingency  operation  in  low-intensity  conflict  magnifies  the  impact  of 
these  constraints.  In  a  COLIC,  quick  response  is  often  complicated  by 
no-warning  response,  in  that  units  have  little — if  any — time  to  prepare  for 
what  lies  ahead.  Since  COLICs  generally  fall  outside  of  mainstream  con¬ 
tingency  planning,  there  is  a  much  greater  likelihood  that  the  terrain, 
climate,  and  culture  actually  encountered  will  be  different  than  those  which 
were  anticipated  or  exercised.  Since  COLICs  are  usually  smaller  in  scale 
than  other  contingencies,  they  place  greater  strain  on  coordination  and 
support  channels  simply  because  fewer  people  are  involved  in  supporting 
the  operation.  Moreover,  the  communications  network  in  COLICs  is  likely 
to  be  smaller  and  less  robust,  but  certainly  no  less  important,  than  in  other 
contingencies.  Because  a  COLIC  usually  involves  fewer  units,  each  one — 
hence,  each  person — plays  a  proportionately  more  critical  role  in  overall 
mission  success  than  it  would  in  larger  contingencies.  As  a  result,  unpre¬ 
dictable  mission  elements  are  multiplied  in  a  COLIC. 

The  types  of  missions  categorized  under  COLICs  add  to  the  difficulties  in 
training  and  preparation  that  units  face.  Missions  such  as  shows  of  force, 
operations  to  restore  order,  noncombatant  evacuation,  and  support  to 
counterdrug  operations2  do  not  fit  the  stereotypical  ideas  that  military 
personnel  have  about  what  they  will  be  called  upon  to  do  in  defense  of  their 
country.  When  suddenly  asked  to  perform  one  of  these  missions,  unit 
personnel  are  likely  to  experience  apprehension  and  confusion — beyond 
that  for  more  “typical"  missions — about  what  their  roles  will  be.  In  new 
situations,  people  tend  to  rely  on  experience  arid  training  to  cope  with  the 


38 


unexpected.  Lacking  these,  people  will  likely  base  their  actions  on  what 
they  know  best — their  day-to-day  tasks  that  support  the  unit. 

The  vagaries  of  COLICs  have  clear  implications  for  mission  automation, 
whether  it  is  provided  by  small  computers  or  mainframes.  Introducing  new 
or  different  automated  processes  Into  units  for  the  purpose  of  supporting  a 
contingency  complicates  a  unit’s  ability  to  perform  its  mission,  at  least  until 
procedures  are  modified  to  match  the  capabilities  or  limitations  of  the 
automated  system.  In  some  COLICs,  time  does  not  permit  system  acclima¬ 
tion.  Although  war  allows  one  to  field-test  a  new  system,  COLICs  do  not 
make  good  test-beds  because  they  seldom  permit  another  chance  if  the  test 
goes  poorly.  Even  if  the  test  is  successful,  the  uniqueness  of  each  COLIC 
makes  it  difficult  to  draw  general  conclusions  about  a  system’s  charac¬ 
teristics.  Under  these  circumstances,  units  employed  in  COLICs  must  have 
systems  with  which  they  are  familiar — preferably  those  that  they  use  daily. 
If  units  are  using  small  computers  to  support  their  daily  operations,  either 
these  computers  should  accompany  them  on  COLIC  deployments  or — if 
small  computers  are  deemed  inappropriate  for  support  during  hostilities — 
the  units  should  have  access  to  “wartime  suitable"  automated  sycfer.is.  But 
replacing  standard  small  computers  with  special  mission-support  com¬ 
puters  in  units  throughout  the  Air  Force  would  be  very  costly  indeed. 


COLIC  Missions 

The  final  draft  of  Joint  Publication  (Pub)  0-1,  “Basic  National  Defense 
Doctrine,"  provides  a  general  description  of  military  operations  short  of  war 
(i.e..  those  undertaken  without  a  declaration  of  war)  and  points  out  distinc¬ 
tions  between  these  operations  and  those  in  time  of  war.3  In  fact,  the 
distinctions  are  mere  technicalities  that  hinge  on  issues  related  to  interna¬ 
tional  law  and  the  degree  of  formal  commitment  made  by  the  political 
leadership  of  the  United  States.4  Although  Joint  Pub  0- 1  would  classify  the 
recent  military  action  in  the  Persian  Gulf  as  an  operation  short  of  war,  the 
conflict  would  certainly  be  well  above  the  level  of  low  intensity  in  terms  of 
mission  support.  Most  predictions  of  likely  future  contingencies  indicate 
that  they  will  be  well  below  large-scale  conventional  war  on  the  spectrum 
of  conflict.5  Therefore,  one  needs  more  specific  characteristics  of  COLICs 
than  those  provided  by  Joint  Pub  0-1. 

Joint  Test  Pub  3-07,  “Doctrine  for  Joint  Operations  in  Low  Intensity 
Conflict,"  better  describes  COLICs  and  divides  them  into  nine  categories: 

•  Disaster  Relief 

•  Shows  of  Force 

•  Noncombatant  Evacuation  Operations 

•  Recovery 
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•  Attacks  and  Raids 

•  Freedom  of  Navigation  and  Protection  of  Shipping 

•  Operations  to  Restore  Order 

•  Security-Assistance  Surges 

•  DOD  Support  to  Counter  drug  Operations6 

More  complete  descriptions  of  these  missions  appear  in  the  appendix. 

Airlift  plays  a  major  role  in  disaster  relief,  noncombatant  evacuation 
operations,  recovery,  and  security-assistance  surges.  The  tactical-combat 
and  special-operations  arms  of  the  Air  Force  can  be  critical  to  the  success 
of  shows  of  force,  attacks  and  raids,  freedom  of  navigation  and  protection 
of  shipping,  operations  to  restore  order,  and  DOD  support  to  counterdrug 
operations.  Disaster  relief,  shows  of  force,  operations  to  restore  order,  and 
DOD  support  to  counterdrug  operations  could  involve  building  or  preparing 
an  air  base  for  flying  operations  and  therefore  require  bare-base  support 
functions.  Any  mission  that  required  deployment  for  more  than  a  few  days 
would  need  normal  support  functions.  In  short,  because  future  COLICs 
will  likely  involve  the  Air  Force — as  they  have  in  the  past — many  types  of 
Air  Force  units  must  be  prepared  to  participate.  This  preparation  includes 
planning  for  automation  support. 


Looking  at  Air  Force  Functions 

The  Air  Force  is  made  up  of  many  functional  components.  A  glance  at  a 
MAJCOM  organizational  chart  reveals  many  functional  "departments."  For 
example,  TAC  is  divided  into  command,  personnel,  inspections,  intel¬ 
ligence,  operations,  plans,  requirements,  safety,  medical,  logistics,  public 
affairs,  weather,  the  chaplaincy,  administration  (information  management), 
financial  (comptroller),  communications/computers,  engineering  and  ser¬ 
vices.  security,  and  legal.7  In  a  broad  sense,  however,  one  might  group 
these  functional  areas  into  several  core  functions: 

1.  Execution  (command  and  control,  operations,  plans,  and  require¬ 
ments) 

2.  Sustainment  (logistics  and  food  services) 

3.  Data  Support  (communications,  intelligence,  and  weather)8 

4.  Infrastructure  (engineering,  housing  services,  finance,  security,  ad¬ 
ministration,  manpower,  training,  legal,  public  affairs,  and  inspections) 

5.  Human  Support  (personnel,  medical,  and  the  chaplaincy) 

Within  each  of  these  core  functions,  many — if  not  all — functioned  missions 
can  be  involved  in  COLICs.  Most  of  these  mission  areas  currently  benefit 
from  day-to-day  small-computer  support  and,  therefore,  could  be  expected 
to  benefit  from  small-computer  support  during  a  COLIC.  Some  of  these 
missions  lend  themselves  especially  well  to  small-computer  support. 
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Small-Computer  Support  in 
COLICs:  A  Mission  Perspective 

To  get  a  better  idea  of  how  small  computers  can  help  units  accomplish 
their  missions  during  COLICs,  one  can  examine  selected  mission  elements 
within  each  core  function.  Depending  on  the  type  of  COLIC  and  the  level 
of  Air  Force  involvement,  these  missions  will  have  differing  degrees  of  impact 
on  the  overall  success  of  the  COLIC.  Each  of  these  missions,  however, 
represents  a  key  function  in  virtually  all  types  of  Air  Force  operational 
employment — at  the  COLIC  level  of  conflict  or  above.  Some  of  the  types  of 
assistance  and  tools  discussed  below  either  already  exist  or  are  in  some 
stage  of  development.  Others  are  notional. 

Execution 

All  aspects  of  mission  execution  could  potentially  benefit  from  some 
degree  of  automated  support.  The  area  of  operations,  for  example,  uses 
many  small-computer-based  tools  to  assist  with  mission  planning  and 
execution.  Because  execution  planning  plays  such  a  central  role  in  COLICs, 
however,  it  is  a  likely  target  for  automation  assistance.  The  need  for  precise 
timing  and  extensive  force  coordination  in  most  COLICs  demands  detailed 
planning  and,  if  possible,  rehearsal  of  the  plan.  Further,  unfamiliar 
locations,  customs,  and  laws  place  added  strain  on  mission  planners.  At 
best,  because  of  the  uniqueness  of  each  COLIC,  one  may  have  to  tailor  an 
off-the-shelf  plan  extensively  for  the  mission  at  hand.  At  worst,  the  plan 
may  be  totally  inapplicable.  These  factors,  coupled  with  the  desire  of  the 
national  command  authorities  (NCA)  to  place  the  greatest  amount  of 
accountability — hence,  execution  authority — at  the  lowest  levels  of  opera¬ 
tional  command  in  a  COLIC,  result  in  mission  commanders  and  their  staffs 
performing  detailed  execution  planning  in  a  time-compressed,  possibly 
secretive,  environment.  Any  assistance — especially  the  type  that  does  not 
require  one  to  obtain  additional  personnel  and  equipment  (as  is  the  case 
with  unit-owned  small  computers) — would  be  extremely  beneficial. 

Unit-level  personnel  who  are  asked  to  deploy  and  operate  in  an  unfamiliar 
area  face  a  substantial  planning  problem.  If  less  than  a  full  contingent  of 
personnel  is  requested,  the  commander  must  decide  who  deploys.  By 
evaluating  the  proposed  mission  in  light  of  information  about  the  terrain 
and  potential  threat,  a  commander  can,  for  example,  select  aircrews  whose 
qualifications  best  match  the  ones  that  are  needed.  Whether  the  deploy¬ 
ment  Is  full  or  partial,  the  personnel  and  equipment  must  get  to  the  remote 
location  expeditiously,  a  feat  which  requires  detailed  deployment  planning. 
Once  on  station,  iegaidless  of  the  type  of  flying  operations  involved,  one 
must  establish  some  sort  of  operational  framework  that  normalizes  flying 
operations  as  much  as  possible  In  the  absence  of  the  extensive  infrastruc¬ 
ture  available  at  the  home  base.  This  framework  includes  local  procedures, 
airspace  management,  crew-duty  scheduling,  target  and  general  mission 
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planning,  and  weapons-related  training  and  analysis.  In  addition,  one 
must  establish  interfaces — automated  or  otherwise — to  the  command  and 
control,  intelligence,  weather,  and  logistics  frameworks.  Once  operations 
commence,  the  unit  requires  a  method  of  assessing  effectiveness.  At  the 
end  of  the  contingency,  the  process  of  dismantling  this  framework  and 
redeploying  will  require  much  of  the  same  planning  and  control. 

Small  computers  can  help  execute  each  of  these  tasks,  albeit  to  varying 
degrees,  depending  on  the  availability  of  near-real-time  data.  Furthermore, 
since  these  activities  are  similar  to  those  performed  at  the  home  base,  using 
small  computers  to  support  them  need  not  be  an  ad  hoc  process  during  the 
contingency.  That  is,  unit  personnel  can  exercise  and  plan  for  small- 
computer  support  on  a  daily  basis. 

Sustainment 

All  functions  of  force  sustainment  lend  themselves  well  to  automated 
support.9  Supply,  in  particular,  has  a  long  history  of  automation  in  the  Air 
Force.10  The  sheer  volume  and  variety  of  supply  items  required  to  support 
operations,  even  COLIC-size  operations,  call  for  some  kind  of  management 
and  control  assistance.11  Transportation,  though,  is  perhaps  the  most 
encompassing  aspect  of  force  sustainment.  As  the  initial  deployment  of 
Operation  Desert  Shield  pointed  out,  transportation  can  be  the  linchpin  of 
success  in  a  show  of  force.  In  disaster  relief  and  recovery,  transportation 
is  the  central  mission.  Because  air  and  ground  transportation  assets  are 
critical  (almost  eveiy  other  aspect  of  an  operation  depends  on  them),  they 
must  be  efficiently  managed. 

Although  current  thinking  emphasizes  the  procurement  of  weapons  and 
support  systems  that  share  components  and  are  otherwise  interoperable, 
the  fact  remains  that  much  of  the  Air  Force  inventory  consists  of  unique, 
hard-to-maintain  equipment.  This  inventory  structure  makes  it  difficult 
for  the  supply  system  to  get  the  right  part  to  the  right  place  at  the  right 
time,  even  under  ideal  conditions. 12  The  moment  forces  arrive  at  a  deployed 
site,  they  need  spare  parts,  many  of  which  are  either  pre-positioned  in  a 
(hopefully)  regional  location  or  sent  as  part  of  the  deployment  package. 
Even  when  properly  sized,  this  spares  package  is  designed  to  sustain  the 
force  for  only  a  very  short  time — units  require  resupply  in  any  operation 
that  lasts  more  than  a  few  weeks. 13  Fortunately,  most  COLICs  will  probably 
be  of  short  duration,  but  some — such  as  shows  of  force,  disaster  relief,  and 
counterdrug  operations — have  an  indefinite  time  frame. 

Even  without  resupply,  however,  managing  the  parts  on  hand  requires 
assistance  of  some  kind — usually  automation.  Some  automated  supply 
systems  now  use  small  computers  as  “front  ends"  to  their  in-garrison 
mainframe  computers.  Indeed,  to  have  an  effective  deployment  capability, 
one  must  be  sure  that  all  important  supply  systems  adopt  this  configura¬ 
tion.  In  this  way,  small-computer-based  applications  that  could  substitute 
for  the  more  extensive  base-level  systems  during  a  deployment  can  share 
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operating  characteristics,  data  requirements,  and  communications  ar¬ 
chitectures  with  their  bigger  brethren.  The  in -garrison  and  deployed 
systems  would  be  similar,  and  functional  managers  could  plan  operational 
and  support  procedures  with  a  high  degree  of  confidence. 

Transportation  units  share  many  operational  difficulties  with  supply 
units,  but  their  most  difficult  problems  deal  with  time  and  space — more 
practically  called  scheduling  and  loading.  In  the  Air  Force,  the  transporta¬ 
tion  function  is  divided  into  air  and  ground  components.  However,  the  air 
component  is  of  such  a  magnitude  that  an  entire  MAJCOM  (Military  Airlift 
Command)  is  devoted  to  it  and  will  be  the  focus  here.14  As  noted  earlier, 
several  COLICs  depend  heavily  on  air  transportation  for  their  success.  In 
DOD  crisis-action  planning,  one  uses  a  large  automated  system — the  Joint 
Deployment  System  (JDS) — to  determine  transportation  feasibility  for 
potential  force-deployment  packages.15  Unfortunately,  to  schedule 
transportation  assets  and  assign  vehicle  routing,  this  system  relies  on 
several  assumptions  about  friendly  and  allied  support,  crisis-response 
time,  and  status  of  forces  that  may  not  be  valid  in  many  COLICs.  In  fact, 
JDS  failed  to  perform  adequately  in  Operation  Desert  Shield  for  this  very 
reason,  as  well  as  its  lack  of  realistic  testing. 16 

One  of  the  problems  with  monolithic  automated  systems  is  that  if  they 
fail,  there  is  no  lesser  automated  capability  to  take  over;  in  other  words,  the 
failure  is  total.  A  more  robust  approach  to  the  JDS  problem  would  be  to 
equip  each  aerial  port  with  independent,  but  interconnected,  smaller 
systems  capable  of  planning  the  routing  of  aircraft  and  vehicles  under  a 
variety  of  situations  with  respect  to  their  particular  node  in  the  entire 
transportation  network.  Not  only  would  system  failures  (either  physical  or 
logical)  be  regionalized,  but  also  one  could  exercise  the  systems  at  the 
various  nodes  locally  and.  therefore,  more  aggressively.  In  this  configura¬ 
tion,  the  JDS  would  be  a  sum  of  its  parts,  and  the  central  planning  module 
would  be  transformed  into  a  much  simpler  nodal  transportation  problem 
using  more  accurate  node-capacity  information.  At  the  unit  level,  cargo- 
loading  optimization  (discussed  in  chap.  1),  packaging,  and  crew  scheduling 
are  examples  of  tasks  which  can  rely  on  small  computers  when  units 
operate  remotely.  Using  these  systems  every  day  would  build  in  crisis 
reliability. 

Data  Support 

Communications  and  intelligence  are  key  aspects  of  any  military  opera¬ 
tion  but  are  especially  critical  in  a  COLIC.  In  many  COLIC  scenarios, 
host-nation  communications  support  is  limited  or  nonexistent.  Further¬ 
more,  the  physical  and  technical  demands  imposed  on  communications 
equipment  and  personnel  by  remote  COLIC  operating  locations  often  cannot 
be  adequately  simulated  during  exercises.17  Intelligence  is  a  particularly 
acute  issue  during  COLICs  due  to  (probable)  regional  unfamiliarity  and 
limited  on-site  intelligence -processing  staffs  and  equipment,  as  well  as  the 
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critical  role  of  human  intelligence  and  the  time  sensitivity  of  COLIC  opera¬ 
tions  (i.e.,  the  need  for  immediately  “usable"  intelligence  data).18  In  addi¬ 
tion,  traditional  methods  for  gathering  technical  intelligence  may  be  ill 
suited  for  the  LIC  environment. 

If  any  area  of  technology  has  advanced  more  rapidly  than  computing 
during  the  past  decade,  it  has  been  communications.  The  1980s  saw 
communications  networks  go  from  massive,  bundled  copper  wires  connect¬ 
ing  mechanical  switching  machines  linked  by  low-bandwidth  cable  and 
radio  and  a  few  satellites  to  fiber  optically  connected  digital  switches  linked 
by  microwave  relay  stations  and  many  high -bandwidth  satellites.  After 
encountering  communications  problems  in  Grenada  (Operation  Urgent 
Fury),  DOD  invested  heavily  in  programs  that  would  ensure  reliable  field 
communications.19  Consequently,  we  now  have  a  cornucopia  of  portable, 
highly  capable  communications  systems  that  reach  down  to  the  lowest 
operational  levels.  In  a  related  field,  electronic  combat  came  out  of  the 
closet  and  onto  the  battlefield  at  all  levels  of  military  operations.20 

With  dramatic  improvements  in  communications  availability,  capability, 
and  flexibility  came  equally  dramatic  increases  in  the  complexity  of  com¬ 
munications  networks.  Although  one  may  still  be  able  to  sketch  the 
architecture  of  a  tactical  communications  network  on  a  piece  of  paper,  one 
can  no  longer  visualize  the  physical  connections.  Terms  such  as  artificial 
neural  node  analysis  have  crept  into  the  communications  jargon.  Because 
so  much  of  the  communications  network  is  controlled  by  computers,  these 
machines  are  also  necessary  to  design  and  analyze  it.  In  a  home-base 
environment,  one  has  the  luxuries  of  time  and  stability  for  conducting  such 
design  and  analysis.  In  a  rapid-response  COLIC,  however,  speed  and 
flexibility  are  paramount.  Thus,  with  regard  to  field  applications, 
automated  design-and-analysis  tools  for  a  communications  network  seem 
appropriate.  Further,  communications  units  not  only  regulate  the  utiliza¬ 
tion  of  voice  and  data  frequencies,  but  also  they  must  advise  operations  on 
electronic  combat  activities.  In  addition,  new  communications  and  radar 
systems  have  widened  the  frequency  band  that  must  be  managed.  The 
vagaries  of  joint  and  combined  operations  add  to  such  frequency- manage¬ 
ment  problems.  Here  again,  small-computer  support  can  play  a  substantial 
part  in  assuring  the  effectiveness  of  operations. 

Systems  for  the  collection  and  distribution  of  intelligence  benefit  greatly 
from  advances  in  sensor  and  communications  technology.  The  trend  now 
is  to  move  away  from  active  signal  intelligence  and  chemical-process  image 
intelligence  toward  passive  signal  receivers  and  digital  (electro-optical) 
imaging  sensors.  This  trend  opens  the  door  for  real-time  data  transmission 
from  sensors  to  remote  small  computers.  By  processing  large  amounts  of 
data  and  turning  it  into  information,  new-generation  microprocessors  will 
make  possible  the  fusion  of  intelligence  data  in  remote  locations.21 

Because  “the  biggest  problem  (in  LICj  is  finding  the  enemy,”22  human 
intelligence  also  plays  a  pivotal  role,  especially  where  secrecy  or  cover 
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prohibits  image  intelligence  and  a  low  degree  of  enemy  technical  sophis¬ 
tication  limits  signal  intelligence.  In  addition,  the  political  sensitivity  of 
most  COLICs  demands  extremely  reliable  information — that  which  human 
intelligence  can  best  provide.  Remotely  piloted  vehicles  could  also  transmit 
data  to  small  computers  for  correlation. 

Worldwide  access  to  all-source  intelligence  data,  made  possible  by  new 
communications  capabilities,  adds  to  the  local  commander’s  burden  of 
intelligence  analysis.  Little  of  this  data  would  be  useful  without  some 
degree  of  automated  correlation-and -analysis  support,  especially  if  units 
were  expected  to  share  information  with  allies.  In  fact,  capabilities  for 
processing  tactical  intelligence  are  now  found  in  computer-based  systems 
that  are  becoming  progressively  smaller.  Nevertheless,  small  computers 
will  need  to  maintain  and  analyze  much  of  the  location-specific  information 
such  as  names,  dates,  and  infrastructure. 

Infrastructure 

The  past  decade  has  seen  the  Air  Force  infrastructure  turn  to  automation 
to  some  degree,  much  of  it  on  small  computers.  One  aspect  of  this 
infrastructure — civil  engineering — has  especially  great  potential  for  further 
automated  assistance.  Although  ecology  seems  to  be  the  preoccupation  of 
civil  engineering  nationally.  Air  Force  civil  engineering  continues  to  con¬ 
centrate  much  of  its  energy  on  military-related  disciplines.  The  design, 
construction,  and  maintenance  of  air  bases — especially  in  a  hostile  environ¬ 
ment — is  particularly  important.  This  mission  area  is  most  useful  in  the 
COLIC  arena  and,  therefore,  can  realize  great  benefits  from  small-computer 
automation. 

The  demise  of  the  Air  Force  pamphlet  system  as  a  source  of  engineering 
data  and  procedures  has  strained  civil  engineering  managers  and  trainers 
in  their  effort  to  disseminate  standardized,  accurate  technical  information. 
A  great  deal  of  money  went  into  automating  base  civil  engineering  units  and 
creating  data  bases  to  replace  the  publications.  Unfortunately,  over  the 
years  much  of  the  procedural  information  eroded  as  the  development  of 
software  that  was  to  embody  the  procedures  lagged  behind  unit  needs.  As 
noted  earlier,  conflicts  arose  between  developmental/ functional  centers 
and  units  over  the  types  and  functions  of  mission-support  software  needed. 
Despite  this  rift,  both  units  and  centers  developed  several  excellent  tools. 
No  doubt,  they  will  develop  many  more. 

When  designing  a  bare  base,  one  must  consider  several  Issues  that  are 
critical  to  safety  and  operational  effectiveness.  The  runway,  of  course,  must 
be  adequate  to  support  the  expected  flying  operations.  Runway  design, 
however,  involves  complex  relationships  and  variables,  many  of  which  are 
based  on  estimates.  Small-computer  automation  can  help  designers  sift 
through  these  factors  accurately  and  quickly.  Weapons  storage  facilities 
must  be  in  locations  that  minimize  the  risk  of  secondary  explosions,  while 
remaining  accessible  to  ground  crews.  Accurately  determining  such  safe 
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zones  for  a  collection  of  many  different  kinds  of  weapons  requires  automated 
support,  especially  if  terrain  limits  one’s  options.  Work  scheduling  and 
material  distribution  during  the  construction  phase  are  other  candidates 
for  automation,  as  are  load-bearing  and  environmental-stress  calculations. 
Beyond  the  normal  base-maintenance  functions,  battle-uamage  and  rapid- 
runway-repair  operations  demand  the  quick  and  accurate  solutions  that 
computers  can  provide.  The  small  amount  of  time  for  selecting  site  options 
during  some  COLICs  does  not  leave  much  room  for  error.  Small  computers 
can  help  one  stay  within  this  margin  in  the  detailed  and  highly  technical 
world  of  civil  engineering. 

Human  Support 

Like  infrastructure,  all  aspects  of  the  human-support  function  have 
turned  to  automation  for  many  missions.  Taking  their  lead  fi  _>m  the  civilian 
health-care  industry  in  the  United  States.  Air  Force  medical  units  continue 
to  undergo  rapid  technological  change.  At  the  same  time,  however,  military 
medical  care  in  the  field  has  always  been  hampered  by  adverse  physical 
conditions,  makeshift  facilities,  and  the  threat  of  hostile  action.  Perhaps 
more  than  other  types  of  conflict,  COLICs  stretch  field  medicine  to  its  limits 
by  adding  complicating  factors:  dependency  on  host-nation  support, 
restricted  supply  and  evacuation  capacity,  and  acute  manpower  shortages 
in  the  face  of  the  potentially  overwhelming  needs  of  the  indigenous  popula¬ 
tion.  Thus,  any  assistance — from  small  computers  or  other  technologies — 
would  be  helpful. 

One  can  evaluate  health  care — especially  field  medicine — according  to 
two  criteria:  quantity  and  quality.  Although  in-gan  ison  medical  treatment 
facilities  are  crowded,  much  of  the  health  care  provided  there  is  collateral 
when  one  compares  it  to  procedures  required  in  hostile  or  disaster  situa¬ 
tions.  In  many  ways,  even  a  heavy  stateside  patient  load  does  not  adequate¬ 
ly  prepare  medical  personnel  lor  the  rigors  of  field  medicine.  Except  for 
(perhaps)  large  urban  areas,  even  the  traumas  cf  hospital  emergency  roonu 
pale  in  comparison  to  the  horrors  of  war  or  disaster.  Clearly,  then,  without 
augmentation  by  man  or  machine,  understaffed  medical  units  operating 
under  extreme  stress  in  the  field  will  be  forced  to  choose  between  quantity 
(marginal  care  for  all)  and  quality  (excellent  care  for  a  few) — a  choice  no  one 
wants  them  to  make. 

In  many  ways,  technology  can  come  to  the  rescue.  Small-  or  portable- 
computer-based  diagnostic  aids  are  becoming  more  popular  in  emergency 
medical  care  and  would  allow  nonphysicians  in  field  situations  to  perform 
some  of  the  tasks  of  doctors,  who  are  in  short  supply.  Radiology  is  an 
essential  service  but  often  impossible  to  pi  ovide  on  site.  However,  by  using 
portable  scanning  units,  small  computers,  and  satellite  communications, 
one  can  transmit  radiographs  and  medical  reports  between  sites  anywhere 
in  the  world.  In  fact,  this  system  would  give  any  site  access  to  medical 
specialists  in  any  discipline  worldwide.  Small -computer-based  systems 
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can  also  provide  assistance  In  laboratory  analysis  and — in  the  absence  of 
technicians — can  even  interface  with  laboratory  equipment  to  form  an 
automated  laboratory.  Other  systems,  such  as  those  for  checking  drug 
interactions  and  planning  nutritional  needs,  could  help  medical  personnel 
in  disaster  relief  and  nation-building  operations.  The  number  of  potential 
benefits  that  can  accrue  to  field  medicine  from  automation  is  almost 
limitless.  The  net  result  of  employing  some  of  this  capability  would  be  to 
enhance  both  the  quantity  and  quality  of  medical  treatment  in  the  field. 


A  Composite  View 

Ideas  about  consolidating  and  broadening  one’s  view  of  missions  are 
gaining  momentum  in  the  Air  Force.  In  fact,  Gen  Merrill  A.  McPeak.  Air 
Force  chief  of  staff,  is  implementing  a  program  to  form  consolidated  flying 
wings  in  the  United  States  and  overseas.  Tailored  to  meet  specific  missions, 
these  wings  will  be  composed  of  various  types  of  aircraft  and  support  units. 
Of  particular  Interest  is  the  composite  wing  planned  for  Mountain  Home 
AFB,  Idaho,  which  will  organize  and  train  to  perform  special  missions 
similar  to  the  attack  on  Libya  (Operation  El  Dorado  Canyon).23  Obviously, 
this  wing  will  be  capable  of  responding  to  various  types  of  COLICs. 

The  philosophy  behind  composite  wings  is  similar  to  the  rationale  for 
supporting  units  that  attempt  to  automate  by  using  small  computers:  “Give 
them  a  mission,  the  resources  to  accomplish  it.  and  broad  guidance  and 
let  them  work  out  the  details."24  This  is  the  kind  of  help  that  units  need  to 
help  themselves.  Functional  managers  should  provide  resource  and  task- 
specific  assistance,  as  well  as  a  framework  for  sharing  information  among 
units,  and  then  stand  back  while  units  come  up  with  creative  and  cost- 
effective  automated  tools.  Similarly,  the  communications-computer  com¬ 
munity  should  provide  technical  assistance  to  both  the  functional 
managers  and  units  directly — with  a  hands-off  attitude — and  provide  stan¬ 
dards  for  hardware,  software,  interface,  and  development.  Once  developers 
reach  the  limit  of  their  abilities  or  once  the  system  is  ready  for  technical 
testing,  integration,  or  other  “professional”  services,  all  parties  must  work 
together  to  ensure  the  creation  of  adequate  documentation,  the  provision 
for  long-term  maintenance  (if  required),  and  the  implementation  of  proper 
procedures. 

The  time  may  come  when  personnel  identify  more  with  the  overall  mission 
that  they  support  than  with  their  functional  area  of  expertise.  Composite 
units  will  be  more  “generic"  and,  therefore,  potentially  more  employable  in 
a  wider  range  of  missions  than  conventionally  organized  units.  Coordinated 
exploitation  of  small  computers  and  support  of  units  by  functional 
managers,  the  technical  community,  and  the  mission  chain  of  command 
will  create  an  environment  where  small  computers  can  be  as  flexibly 
employed  as  the  units  themselves.  The  citizens  of  the  United  States  will  be 
the  big  winners.  Not  only  will  the  reduced  cost  of  developing  automated 
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systems  save  their  tax  money,  but  also  they  will  be  protected  by  an  Air  Force 
that  is  better  able  to  meet  a  broader  range  of  contingencies. 


Notes 
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and  the  way  they  fit  into  JOPS  appear  throughout  JCS  Pub  5-02.3.  Joint  Operation  Planning 
System :  ADP  Support,  vol.  3.  7  August  1985.  Time- sensitive  contingency  operations  use  a 
crisis-action  planning  process,  as  described  in  JCS  Pub  5-02.4,  Joint  Operation  Planning 
System  Crisis  Action  Procedures,  vol.  4.  8  July  1988. 

2.  Joint  Test  Pub  3-07,  “Doctrine  for  Joint  Operations  in  Low  Intensity  Conflict,”  October 
1990.  V-5  through  V-9. 

3.  Joint  Pub  0-1,  “Basic  National  Defense  Doctrine."  final  draft,  24  July  1990.  11-22 
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4.  Ibid..  U-23. 

5.  Richard  H.  Shultz.  Jr..  “Low-Intensity  Conflict  and  US  Policy:  Regional  Threats,  Soviet 
Involvement,  and  the  American  Response."  in  Low-Intensity  Conjlict  and  Modem  Technology. 
ed.  Lt  Col  David  J.  Dean  (Maxwell  AFB,  Ala.:  Air  University  Press,  June  1986).  77. 

6.  Joint  Test  Pub  3-07,  V-5  through  V- 10.  Some  other  documents  label  these  types  of 
military  activities  peacetime  contingency  operations.  This  study  assumes  that  the  terms  are 
equivalent. 

7.  TAC  Visual  Aid  11  1.  Langley  AFB.  Va..  December  1989. 

8.  Note  that  computers  are  missing  as  a  function  under  data  support.  In  my  view, 
computers  are  simply  tools  which  are  employed  in  each  functional  area  and,  hence,  do  not 
fall  into  a  separate  functional  category. 

9.  Capt  Donald  C.  Fandre.  “Interim  Deployable  Maintenance  System,”  Report  no. 
LM840302  (Gunter  AFB,  Ala.:  Air  Force  Logistics  Management  Center,  June  1987).  1.  In 
addition  to  describing  computer  dependency  in  the  maintenance  function.  Captain  Fandre 
points  out  that  deployed  operations  are  not  very  well  supported  by  automation. 

10.  Logistics  was  one  of  the  first  areas  that  the  Air  Force  considered  for  automation.  See 
Sidney  H.  Miller.  “Electronic  Computers  and  Air  Logistics,"  Special  report  no.  43D  (Maxwell 
AFB,  Ala.:  Air  Command  and  Staff  College,  1956).  As  discussed  in  chapter  2,  the  first 
computers  in  the  Air  Force  were  used  for  fin  since  and  supply. 

1 1.  “Supply  and  Command,"  The  Economist.  26  January  1991,  79.  The  Air  Force  has 
over  6  million  spare  parts  in  its  inventory. 

12.  Ibid.  The  system  used  in  Saudi  Arabia  directly  linked  deployed  supply  units  with 
stateside  air  logistics  centers  for  ordering  spare  parts,  tracking  status,  and  distributing 
material. 

13.  “Accuracy  of  Selected  Data  Used  in  Aircraft  Wartime  Spares  Requirements."  Audit 
Report  (Washington.  D.C.:  Air  Force  Audit  Agency,  3  May  1990).  This  report  found  that 
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Chapter  5 

Recommendations  and  Conclusion 


At  first  glance,  there  might  appear  to  be  too  many  recommendations  in 
this  chapter,  or  at  least  more  than  is  usually  associated  with  studies  of  this 
scope.  When  considered  together,  however,  the  recommendations  paint  a 
picture  from  a  limited  palette.  The  central  idea  is  simple — to  taki  other 
advantage  of  unit -level  automation  within  a  structure  that  is  better  or¬ 
ganized  to  do  so.  Some  recommendations  directly  relate  to  small  computers 
and  unit-level  automation;  others  do  so  only  indirectly  if  at  all. 


Philosophical  Recommendations 

Automation  of  mission  tasks  requires  a  different  acquisition  philosophy 
than  that  for  major  weapons  systems.  Whereas  it  is  unreasonable  to  expect 
line-level  organizations  to  research,  design,  produce,  and  sustain  a  new 
aircraft  autonomously,  it  is  not  unreasonable  for  individual  units — or  a 
collection  of  similar  ones — to  define  requirements,  develop  prototypes,  and 
test  solutions  for  mission  automation,  particularly  that  based  on  small 
systems.  The  tendency  to  look  toward  contractors  or  central  developers  for 
an  omnibus  solution  to  every  automation  problem  is  inconsistent  with  the 
evolving  Air  Force  doctrine  for  projecting  power.1  The  Air  Force  can  no 
longer  tie  itself  to  long,  vulnerable,  slow-reacting  support  channels,  such 
as  those  based  almost  exclusively  on  central  automation. 

1 .  Senior  leadership  should  look  to  end-user  computing  as  a  first  source 
of  unit-level  mission  automation  and  fully  explore  this  option  before  seeking 
more  extensive  solutions. 

2.  The  Air  Force  should  reduce  the  number  of  central  data  bases, 
especially  those  which  primarily  serve  as  collectors  of  management  infor¬ 
mation,  and  move  to  an  information  architecture  characterized  by  data 
storage  located  as  close  as  possible  to  the  point  of  data  collection.  Assuming 
proper  data-interchange  standards,  management  information  could  then 
be  collected  as  needed  at  the  various  levels  up  the  reporting  chain  without 
affecting  the  ability  of  managers  and  technicians  to  use  this  information  at 
lower  levels.2 

3.  The  Air  Force  Inspector  General  (AF/IG),  through  the  Air  Force 
Inspection  Center,  should  greatly  reduce  or  stop  recommending  Air  Force¬ 
wide  or  functionwide  automated  management -control  systems  as  a  part  of 
broadbrush  solutions  to  specific  problems.  Instead,  the  IG  should  promote 
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standard  data-exchange  formats  and  recommend  reporting  procedures 
rather  than  reporting  systems. 

Organizational  Recommendations 

The  Air  Force  will  undergo  many  organizational  changes  In  the  coming 
years  as  it  seeks  greater  efficiencies.  Some  of  these  changes  will  be 
downward-directed,  but  most  will  not.  In  either  case,  there  will  be  a 
tendency  to  consolidate  and  centralize  functions  wherever  feasible,  using 
the  logistics  community  as  a  model.  When  applied  to  automation,  however, 
centralization  goes  beyond  the  logistics  model  and  violates  the  principle  of 
centralized  control  and  decentralized  execution  because  by  completely 
centralizing  a  system,  one  also  centralizes  execution.  Furthermore,  com¬ 
puter  applications  and  software  deal  with  creative  processes,  which  require 
the  close  involvement  of  users.  Such  involvement  is  difficult  to  achieve  with 
central  systems  because  of  the  diversity  of  users  who  are  affected.  Never¬ 
theless.  there  undoubtedly  will  be  greater  centralization.  Consequently, 
with  respect  to  automation,  the  Air  Force  should  adopt  an  organizational 
structure  which  is  designed  to  capitalize  on  the  skills  of  unit  personnel  and 
allow  the  free  flow  of  ideas. 

1 .  The  Air  Force  should  reduce  the  number  of  people  at  central  computer 
centers  above  wing  level  or  outside  of  “mission  chains”  (such  as  inde¬ 
pendent  central-design  activities). 

2.  Every  unit  that  needs  end-user  computing  to  perform  its  mission 
should  have  a  computer  specialist.3  This  person  would  be  the  point  of 
contact  (POC)  for  automation  issues  that  affect  the  unit  and  would  help 
solve  computer-related  problems,  both  technical  and  procedural.  Further, 
the  computer  specialist  could  assist  with  or  perform  mission-related 
software  development.  Both  SC  and  the  Air  Force  Communications  Agency 
(AFCA)  should  manage  policy,  procedures,  and  training  for  these  personnel, 
but  the  units  should  retain  operational  control. 

3.  The  Air  Force  should  establish  a  small  number  of  computer  specialist 
positions  in  each  wing  to  coordinate  unit-level  automation  activities  and 
serve  as  technical  POCs  for  non-mission-specific  computing.4  They  could 
also  help  the  units  maintain  a  liaison  with  their  functional  POC  and  be  the 
wing  experts  on  hardware,  software,  and  data  standards. 

4.  Each  Air  Force  functional  area  should  designate  a  single  organization 
to  be  its  POC  for  all  automation  issues.  This  organization  should  closely 
coordinate  with  the  Standard  Systems  Center  (if  a  functional  component  of 
the  center  is  not  the  POC)  for  centrally  developed  or  maintained  systems. 
These  functional  POCs,  through  their  unit  representatives,  should  be  aware 
of  the  software  that  is  used  in  the  units  and  determine  whether  it  is 
mission-standard.  They  must  also  match  procedures  with  changes  in 
automation  and  ensure  that  the  training  community  is  responsive  to  these 
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changes.  For  example.  AFCA  should  be  the  functional  POC  for  communica- 
tions-computer  units  and  personnel. 


Functional  Recommendations 

Now  that  all  Air  Force  functions  are  being  streamlined,  it  becomes  even 
more  important  that  the  computer  community  take  charge  of  automation 
problems  and  provide  broad  leadership.  The  current  climate  in  DOD 
indicates  that  functions  which  are  being  poorly  managed  by  the  services 
are  candidates  for  DOD -wide  centralization.  Current  examples  are  logis¬ 
tics.  contract  management,  and  finances.  Automation  is  a  likely  candidate 
because  of  its  checkered  history  and  the  military  services’  inability  to  get 
control  of  the  software  acquisition  process.  Although  these  issues  are  much 
bigger  than  the  unit-level  automation  problem,  the  Air  Force  computer 
community  can  demonstrate  leadership  by  taking  charge  of  its  function  and 
pointing  the  way  for  future  interoperability  across  functions  and  system 
categories. 

1 .  SC  should  reclaim  its  technical  functions  from  the  MAJCOMs  (such 
as  Air  Force  Logistics  Command)  and  from  other  functional  areas  (such  as 
Air  Force  Information  Management)  and  reassign  them  to  AFCA.  as  ap¬ 
propriate. 

2.  SC.  through  AFCA,  should  establish  a  data-exchange  standard  and 
create  guidelines  for  data-systems  architectures  which  affect  the  fewest 
number  of  users  in  case  of  failures.  This  generally  calls  for  networked 
systems  rather  than  central  servers. 

3.  AFCA  should  provide  technical  leadership  and  assistance  on  auto¬ 
mation  issues  for  the  Air  Force  at  large.  This  role  is  especially  important 
for  AFCA  as  a  coordinating  and  integrating  body  for  the  functional  areas. 
As  part  of  its  technical  leadership  role,  AFCA  should  develop  and  maintain 
automation-related  standards,  to  include  hardware;  software  development, 
tools,  user  interface,  and  documentation;  data  storage  and  exchange; 
operating  systems;  and  systems  Integration  standards. 


Procedural  Recommendations 

Although  one  could  make  many  procedural  recommendations,  it  may  be 
best  to  focus  initially  on  those  that  could  achieve  efficiencies  for  manpower 
and  costs  and  those  that  could  enhance  the  fundamental  role  of  the 
computer  community  in  a  distributed  development-and-execution  architec¬ 
ture. 

1.  The  Air  Force  should  go  to  “lights  out"  operations  at  central  automa¬ 
tion  sites  as  much  as  possible.  As  more  mission  automation  moves  to  lower 
organizational  levels,  central  sites  will  increasingly  become  data- 
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communications  nodes  and  information  repositories.  Their  role  as  hosts 
to  end-user  applications  will  correspondingly  decrease.  This  change  will 
require  less  24-hour,  hands-on  intervention  at  the  central  sites. 

2.  The  Air  Force  should  drastically  reduce  the  amount  of  dedicated 
maintenance  for  central  sites  and  eliminate  dedicated  maintenance  for 
end-user  and  intermediate  sites.5  Further,  it  should  move  to  more  on-call, 
multisystem  maintenance  contracts  which  specify  that  maintenance 
response  times  be  based  on  the  criticality  of  the  mission  automated. 
Normally,  this  would  entail  quicker  maintenance  response  for  systems 
nearest  the  points  of  mission  accomplishment  and  primary  data  collection. 

3.  SC  and  AFCA  should  be  careful  not  to  overcontrol  end-user  applica¬ 
tions  or  procedures.  They  should  limit  their  unit-level  involvement  to 
developing  standards  and  guidelines,  as  well  as  providing  technical  assis¬ 
tance  and  customer  support. 


Conclusion 

Whether  they  are  contiguous  or  created  from  tailored  forces  to  meet 
specific  operational  requirements,  units  called  to  support  a  contingency  rely 
on  procedures  that  they  practice  during  day-to-day  operations.  As  unit 
personnel  use  automation  to  support  more  and  more  of  their  missions,  they 
develop  a  passive  dependency  on  this  automation.  Since  much  automated 
support  is  provided  by  standard  Air  Force  small  computers,  a  unit's  mission 
effectiveness  increasingly  relies  on  the  efficient  utilization  of  these  com¬ 
puters. 

In  the  context  of  contingency  operations  <n  low  intensity  conflict,  one 
must  preplan  small-computer  support  since  time  and  national  sensitivities 
prohibit  doing  something  new  or  different,  especially  in  an  ad  hoc  fashion. 
Low-intensity  conflicts  have  been  called  the  “wars  of  the  1990s.”  If  indeed 
they  are.  then  automation-support  planners  are  faced  with  a  stiff  challenge 
to  meet  the  diverse  demands  of  this  sort  of  warfare,  particularly  if  the  wealth 
of  talent  in  the  units  is  ignored  or  abandoned  in  favor  of  supporting  the 
units’  mission  applications  with  large-scale,  central  systems. 

Fortunately,  small  computers  lend  themselves  well  to  a  LIC  contingency- 
support  role  in  terms  of  physical  size,  capability,  reliability,  and  support- 
ability:  moreover,  their  ease  of  use  allows  units  to  self-automate. 
Recognizing  these  benefits,  many  Air  Force  functions  are  increasingly 
turning  to  standard  small  computers — or  similar  dedicated  mission- 
support  automation — for  just  this  .sort  of  support  for  their  units.  Thus,  the 
circle  of  ever-increasing  automation  is  completed. 

We  cannot  turn  back  the  clock  or  wish  away  technology  in  the  Air  Force. 
Technology  and  automation — and  their  prevailing  influence  on  how  we 
perform  our  missions — are  here  to  stay. 

Gen  Michael  Dugan,  former  Air  Force  chief  of  staff,  said  that  “our  nation 
has  pursued  for  decades  the  policy  that  has  substituted  machines  and 
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technology  for  human  lives.  I  think  ...  we  will  continue  to  pursue  that 
policy.”6  Although  General  Dugan  did  not  have  the  opportunity  to  observe 
Operation  Desert  Storm  as  the  Air  Force  chief  of  staff,  his  words  were 
certainly  played  out  over  the  sands  of  Kuwait  and  Iraq.  A  contingency 
operation  in  low-intensity  conflict  will  require  as  much,  if  not  more, 
technology  than  we  used  in  Operation  Desert  Storm  to  achieve  our  national 
security  objectives  with  minimal  loss  of  life  and  controlled  violence.  Small 
computers  can  be  important  components  in  our  arsenal  of  technology. 


Notes 

1 .  See  Secretary  of  the  Air  Force  Donald  B.  Rice,  The  Air  Force  and  U.S.  National  Security: 
Global  Reach — Global  Power  (Washington.  D.C.:  Department  of  the  Air  Force.  June  1990). 

2.  A  by-product  of  aggregated  central  data  bases  has  been  that  line-level  personnel  often 
do  not  keep  information  locally  and  that  the  central  data  base  tends  to  become  generic  over 
time  and  less  useful  to  lower  levels. 

3.  Many  functional  areas  feel  that  this  type  of  support  is  urgently  needed.  For  one 
example,  see  Maj  Stephen  M.  Baysinger,  “Aircraft  Maintenance  Automation  Support  Per¬ 
sonnel."  Report  no.  LM881292  (Gunter  AFB.  Ala.:  Air  Force  Logistics  Management  Center, 
May  1990). 

4.  These  positions  could  (but  do  not  have  to)  be  in  the  communications  unit.  The  thrust 
of  this  recommendation  is  to  ensure  that  dedicated  positions  exist  and  do  not  need  to  be 
“taken  out  of  hide." 

5.  Dedicated  maintenance  for  computer  equipment,  much  of  which  is  unnecessary,  costs 
about  $450  million  annually.  "Maintenance  Alternatives  for  ADPE.”  Follow-up  Audit 
(Washington.  D.C.:  Air  Force  Audit  Agency.  27  June  1988). 

6.  Quoted  in  The  Microchip  War."  The  Economist,  26  January  1991.  77. 
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Appendix 


Low-Intensity  Conflict 
Contingency  Missions 

Current  documents  classify  nine  mission  categories  under  contingency 
operations  in  low-intensity  conflict.  Depending  on  the  contingency 
scenario,  one  or  more  of  these  missions  could  be  conducted  in  an  operation. 
Because  of  the  political  sensitivities  involved,  the  national  command 
authorities  maintain  a  close  watch  over  the  conduct  of  each  of  these 
missions. 


Disaster  Relief 

Disaster  relief  operations  provide  assistance  to  victims  of  natural  and 
man-made  disasters  outside  of  the  United  States,  usually  at  the  request  of 
the  host  nation.  Specific  functions  of  disaster  relief  include  refugee  assis¬ 
tance,  emergency  medical  care  and  communications,  damage  assessment, 
transportation  and  other  logistical  support,  and  restoration  of  law  and 
order.  Military  relief  activities  are  usually  coordinated  with  the  State 
Department.1  Timely  response  is  critical. 

The  Air  Force  role  in  disaster  relief  centers  on  airlift — transporting 
equipment,  supplies,  and  personnel  to  and  from  the  disaster  area.  If 
conducted  properly,  disaster  relief  airlifts  can  have  effects  that  extend 
beyond  the  assistance  provided  to  the  disaster  victims.  That  is,  the  US  can 
improve  its  strategic  posture  in  the  disaster  area  by  projecting  itself  as  a 
humanitarian  nation  acting  in  friendship,  thus  possibly  avoiding  future 
military  conflicts  in  the  region.2  The  past  decade  alone  provides  numerous 
examples  of  disaster  relief  operations  involving  earthquakes,  storms,  floods, 
and  so  forth. 


Shows  of  Force 

Typical  shows  of  force  include  military  forces  deployed  abroad,  combined- 
nation  exercises,  and  visits  by  aircraft  and  ships.  The  US  can  use  these 
operations  to  demonstrate  support  for  its  friends  and  allies  and  to  under¬ 
score  US  resolve  to  exercise  the  military  arm  of  national  policy.  Shows  of 
force  can  also  influence  another  government  or  political- military  organiza- 
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tion  to  respect  US  interests  or  to  enforce  international  law.  If  one  uses 
shows  of  force  too  often,  however,  negative  psychological  effects  can  result.3 

like  disaster  relief,  shows  of  force  must  be  conducted  in  a  timely  manner 
to  achieve  the  desired  result.  These  operations  rely  on  logistics,  command 
and  control,  communications,  and  intelligence;  they  must  present  the 
appearance  that  the  use  of  the  force  is  both  possible  and  sustainable.  But 
the  mission  of  the  force  is  to  persuade,  not  to  engage  militarily.4  The 
positioning  of  a  naval  aircraft  carrier  battle  group  off  the  coast  of  Lebanon 
in  response  to  terrorist  activities  in  that  country  is  an  example  of  a  show  of 
force,  as  was  the  initial  deployment  in  Operation  Desert  Shield. 

Noncombatant  Evacuation  Operations 

Noncombatant  evacuation  operations  (NEO)  involve  relocating 
threatened  civilian  noncombatants,  usually  US  citizens  living  in  another 
country.  NEOs  can  also  be  conducted  with  respect  to  host-  and  third- 
country  personnel.  These  operations  typically  consist  of  rapid  force  inser¬ 
tion^  temporary  occupation  of  an  objective,  and  planned,  rapid  withdrawal. 
Deadly  military  force  is  used  only  to  protect  the  evacuees  and  for  self- 
defense.  The  US  ambassador  or  the  chief  of  the  diplomatic  mission 
maintains  plans  for  NEOs  and  would  normally  request  militaiy  assistance 
for  evacuation  through  the  State  Department.  Due  to  the  sensitivity  of  these 
operations,  political  considerations  and  constraints  are  of  utmost  impor¬ 
tance  throughout  this  type  of  COLIC.5  The  Grenada  operation  and.  more 
recently,  the  evacuation  of  US  citizens  and  embassy  personnel  from  Somalia 
are  classic  examples  of  NEOs. 

Recovery  Operations 

Recoveries  involve  locating  and  retrieving  US  citizens  or  foreign  nationals, 
sensitive  equipment  (e.g.,  missiles  or  submarines),  or  other  items,  the  loss 
of  which  could  adversely  affect  US  national  security  (e.g.,  fissionable 
material  or  compromising  documents).  The  military  may  conduct  overt, 
clandestine,  or  covert  recovery  operations  in  hostile  or  friendly  territory.6 
The  attempt  to  rescue  US  hostages  in  Iran  is  an  example  of  an  operation  in 
this  category. 


Attacks  and  Raids 

Attacks  and  raids  are  short -duration,  overt  military  operations  carried 
out  for  purposes  other  than  to  capture  or  defend  territory.  Attacks  are 
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limited  conventional  strikes  by  ground,  air,  naval,  or  special  operations 
forces  (or  some  combination  of  these)  against  high-value  targets  to  destroy 
them  or  exhibit  the  national  resolve  and  capacity  to  do  so.7  They  can  be  an 
extension  of  a  show  of  force  or  an  effort  to  support  a  recovery  or  counterdrug 
operation.8  Raids  are  typically  small-scale  operations  that  penetrate  a 
hostile  area  to  gain  information,  temporarily  seize  an  objective,  destroy  a 
specific  target,  or  capture  an  enemy.  Both  attacks  and  raids  are  planned 
to  end  with  withdrawal.9 

Since  attacks  and  raids  involve  open  displays  of  force,  the  US  must 
exercise  care  to  prevent  escalation.  This  requires  careful  planning  that 
considers  the  ethical,  legal,  and  political  (as  well  as  the  military)  aspects  of 
the  mission.  Consequently,  the  NCA  may  directly  monitor  these  operations 
through  the  JCS.10  The  air  strike  on  Libya  to  persuade  its  government  to 
curtail  its  support  of  terrorist  activities  and  the  invasion  of  Panama  to 
capture  strongman  Manuel  Noriega  are  examples  of  an  attack  and  a  raid, 
respectively. 


Freedom  of  Navigation  and  Protection  of  Shipping 

An  armed  attack  on  US  shipping  on  the  high  seas  would  normally 
constitute  an  act  of  war  and,  therefore,  would  be  above  the  level  of 
low-intensity  conflict.  Other  maritime  threats  and  hostile  actions  could 
prompt  a  COLIC  response,  however.  The  military  can  be  directly  involved 
in  coastal  control,  as  well  as  port  and  waterway  security,  for  example.  Area 
operations — such  as  escorts,  countermine  operations,  and  surveillance — 
may  be  employed  to  counter  a  potentially  overwhelming  tactical  maritime 
advantage  by  an  enemy.  Whenever  possible,  the  US  should  use  agreements 
with  friendly  nations  to  multiply  the  effectiveness  of  maritime  security  and 
prevent  this  type  of  COLIC  from  developing. 1 1  The  Mayaguez  incident  and. 
more  recently,  US  escort  of  oil  tankers  in  the  Persian  Gulf  during  the 
Iran-Iraq  war  are  examples  of  this  type  of  COLIC. 12 


Operations  to  Restore  Order 

The  objectives  of  operations  to  restore  order  are  to  force  an  end  to  violence, 
return  control  to  civil  authority  (if  it  is  not  the  cause  of  the  violence),  and 
reestablish  normal  political  processes.13  Usually,  a  foreign  state  requests 
US  intervention,  but  this  COLIC  can  be  initiated  unilaterally  or  multilateral- 
ly  to  protect  citizens  or  other  national  interests.  Since  the  intervening  force 
is  not  a  neutral  party,  these  operations  could  degenerate  into  combat  if 
eveiy  effort  is  not  made  to  reach  a  negotiated  halt  in  the  violence.  If 
successful,  these  COLICs  may  lead  to  follow-on  peacekeeping  activities. 
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Operations  to  restore  order  are  complex  and  unique.  Success  often  depends 
on  integrating  local  laws  and  customs  into  the  local  commander’s  plans.14 
The  US  intervention  in  the  Dominican  Republic  in  1965  and  US  activities 
to  establish  order  in  the  Kurdish  region  of  Iraq  in  1991  fall  into  this  category 
of  operations. 


Security  Assistance  Surges 

When  an  ally  faces  an  imminent  national  security  threat,  the  United 
States  may  support  the  ally  by  accelerating  shipments  of  military  equipment 
or  increasing  training  and  financial  support.  These  operations  usually  rely 
on  airlift  and  sea-lift  capabilities  and  are  governed  by  the  recipient  nation’s 
needs  and  the  constraints  of  geography  and  time.15  The  massive  airlift  of 
military  supplies  and  equipment  to  Israel  during  the  Yom  Kippur  war  in 
1973  is  an  example  of  a  security  assistance  surge.16 


DOD  Support  to  Counterdrug  Operations 

In  all  but  a  few  cases,  the  United  States  restricts  military  involvement  in 
law  enforcement.17  Currently,  however,  lawmakers  feel  that  drug  traffick¬ 
ing  is  enough  of  a  threat  to  national  security  that  ongoing  military 
counterdrug  operations  are  warranted.18  Congress  has  assigned  three 
counterdrug  roles  to  the  Department  of  Defense: 

1.  Act  as  the  lead  federal  agency  for  detecting  and  monitoring  drug 
smuggling  by  air  and  sea. 

2.  Integrate  US  command  and  control,  communications,  and  technical 
intelligence  assets  assigned  to  drug  interdiction. 

3.  Approve  and  fund  each  state’s  antidrug  plan,  which  includes  in¬ 
creased  use  of  the  National  Guard  in  counterdrug  operations.19 

To  carry  out  these  roles,  military  agencies  have  adapted  training  activities 
to  include  counterdrug  operations.  For  example,  airborne  warning  and 
control  system  (AWACS)  aircraft  monitor  borders  and  track  aircraft 
suspected  of  carrying  illegal  drugs,  especially  those  entering  US  airspace. 
Naval  vessels  assist  with  search  and  seizure  operations  in  conjunction  with 
the  Coast  Guard  and  foreign  nations.20  In  cooperation  with  the  State 
Department,  military  forces  also  work  with  law  enforcement  agencies  in 
foreign  countries  to  eliminate  drug  production  and  processing  inside  their 
borders.2 1 

As  public  interest  in  controlling  drug  abuse  increases,  the  US  government 
can  be  expected  to  increase  funding  for  antidrug  programs.  Along  with  this 
increased  funding,  militaiy  involvement  in  counterdrug  operations  will  also 
likely  rise  and  take  on  new  directions.22 
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Glossary 


ADPE 

AFCA 

AFCAC 

AT/IG  (or  IG) 

AFLMC 

AFM 

AFR 

AF/SC  (or  SC) 

AFSCOASO 

AF/SI  (or  SI) 
ATC 

BBS 

BPS 

CALMS 

COLIC 

DOD 

FCC 

FM 

FPLAN 

IBM 

JCS 


automated  data  processing  equipment 

Air  Force  Communications  Agency 

Air  Force  Computer  Acquisition  Center 

Air  Force  Inspector  General 

Air  Force  Logistics  Management  Center 

Air  Force  manual 

Air  Force  regulation 

Air  Force  Deputy  Chief  of  Staff  for  Command,  Control, 
Communications,  and  Computers 

Air  Force  Small  Computer/Office  Automation  Service 
Organization 

Air  Force  Deputy  Chief  of  Staff  for  Information  Systems 
Air  Training  Command 

bulletin  board  system 
bits  per  second 

cargo  automated  loading  management  system 
contingency  operation  in  low-intensity  conflict 

Department  of  Defense 

Federal  Communications  Commission 
field  manual 
flight  planning 

International  Business  Machines  (Corporation) 

Joint  Chiefs  of  Staff 
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JDS 

JOPES 

JOPS 

Joint  Deployment  System 

Joint  Operations  Planning  and  Execution  System 

Joint  Operations  Planning  System 

UC 

low-intensity  conflict 

MAJCOM 

MILSPEC 

MSS 

major  command 

military  specification 

mission  support  system 

NCA 

NEO 

national  command  authorities 

noncombatant  evacuation  operation 

OJT 

on-the-job  training 

PC 

PCO 

POC 

pub 

personal  computer 

peacetime  contingency  operation 

point  of  contact 

publication 

RAM 

RF 

random  access  memory 

radio  frequency 

SCTC 

small  computer  technical  centers 

TAC 

TEG 

TEMPEST 

Tactical  Air  Command 

test  and  evaluation  group 

special  shielding  against  electromagnetic  radiation 
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